vRealize Operations Manager 6 Considerazioni su Architettura e Design
VMUGIT Meeting, Roma, 26 Settembre 2016
Pietro PIUTTI – VMUG Italia Leader, Systems Engineer, VMware vEXPERT, PernixPro, Tech Field Day Delegate
@stingray92 – http://blog.vgeek.it
2
vROps: avevamo bisogno di un altro tool di monitoring?
vCenter vs vROps: è tutta un’altra storia…
• vCenter: Performance Graphs e Alarms
• vROps: metriche, metriche, metriche!! Bagdes, Alerts, Widgets, Reports…
• Presentazione vs Analisi / Perdita di dettaglio vs Granularità e Persistenza
vROps non è solo un tool di monitoring!
• Policy-based Health, Risk and Efficiency analysis
• Troubleshooting, Capacity Planning, Correlazione
vs
3
Ma vROps è solo un rebranding di vCOps?
Stessi obiettivi, stessa filosofia, nuovo prodotto, focus sulla
semplificazione (deployment e operations semplificate):
• vCOps: UI VM + Analytics VM
• vROps: una sola VM può integrare tutti i ruoli
• vCOps: vSphere UI + Custom UI
• vROps: una sola UI
Componente fondamentale della vRealize Suite
• Integrazione “Out of the Box” con Log Insight per troubleshooting avanzato
• NSX ready (con adapter aggiuntivo)
• Integra funzionalità di Hyperic (dalla 6.2) per il monitoring a livello OS e
Applicativo (EPOps)
4
Quale tipo di VM scegliere per il nostro Cluster?
Windows
Linux (RedHat)
OVA Appliance
Omogeneità: tutte le VM del Cluster vROps devono essere
identiche. Si, ma non è proprio vero…
Pro/Contro
• OS Based: vanno gestite secondo gli standard aziendali (patching, backup,
antivirus, agents etc.)
• OVA: “black box” (nessuna modifica permessa, nessuna manutenzione,
aggiornamenti incrementali di OS e applicazione)
• Non esiste una risposta univoca: la scelta dipende dalle logiche
dell’organizzazione
5
Analytics Cluster vROps: ruoli e scalabilità (1/3)
Un Cluster vROps è un Sistema Distribuito che “uses VMware
vFabric® GemFire® to connect nodes into a shared memory cluster and
map the work across the nodes”
vROps è concepito per scalare: si parte sempre dal Master Node e
si espande con l’aggiunta di altri nodi:
• Data Node
• Master Replica (a partire da un Data Node)
• Collector
Internals:
• UI
• Collector
• Controller
• Analytics
• Persistence
6
Analytics Cluster vROps: ruoli e scalabilità (2/3)
La “Persistence” e i 4 DB:
• Global xDB: Contains user configuration data, such as
alert and symptom definitions, dashboard
configurations, and super metric formulas. The global
xDB is found on the master node and master replica
nodes only
• Alerts/symptoms vPostgres: Contains alerts and
symptoms information
• Historical inventory service xDB: Contains a
historical view of all object properties and relationships
• FSDB: Contains all the statistical, time series data.
This raw metric data is used to provide live status
displays in the user interface
7
Analytics Cluster vROps: ruoli e scalabilità (3/3)
Espandere la capacità analitica del Cluster: Data Node
• Stesso OS, stessa taglia, stessa location (no across multiple DCs deployment!)
• DB Sharding
Espandere il raggio d’azione del Cluster: Remote Collector Node
• Nessuna limitazione in termini di OS/taglia, nessuna capacità analitica, non
ospita DB
8
HA: vantaggi e svantaggi
In un Cluster di N nodi analytics, quanti ne possono fallire senza
perdere il Cluster? Risposta: solo 1!
• Se crasha un Data Node? No problem: il carico viene distribuito sui nodi
superstiti finché il Data Node non viene sostituito. Ma facciamo presto!
• E se crasha il Master? Il Master Node è un Single Point of Failure
Soluzione: convertire un Data Node in Master Replica
• Vantaggi:
• No Single Point of Failure
• Failover del Master role e Recovery automatico e veloce del Cluster
• Svantaggi:
• Downsize della capacità analitica del cluster (abbiamo rinunciato ad un Data Node)
• Allocazione di ulteriori risorse infrastrutturali
9
Proteggere un Cluster vROps
Mantenere i nodi analytics su host diversi (DRS anti-affinity rule)
Backup: attenti alla consistenza dei dati
• Il backup (a livello VM, con tool VADP) va fatto non per singolo nodo ma per
tutti i nodi analytics allo stesso tempo
• Il tool di backup va configurato disabilitando la quiescienza del file system
delle VM. Se il tool non lo permette, va disabilitata a livello di singola VM –
Vedi doc ufficiale di prodotto https://goo.gl/0xAFsK
• In caso di restore di un nodo crashato, va fatto il restore di tutti i nodi
(ricordate… consistenza!)
• Schedulare i backup quando non sta girando il task di calcolo dei Dynamic
Thresholds
Abilitare l’HA (Master Replica Node)…. YMMV!
10
Sizing: le dimensioni contano (1/2)
OK, ma quanti nodi? Quanto grandi? Dobbiamo fare due conti:
• Numero di oggetti e relative metriche da “misurare”
• Tempo di retention (default: 6 mesi)
• Numero e tipo di Adapter configurati etc…
I nodi analytics hanno diversi tagli:
Una volta scelto, non si cambia il Node Size (Scale out vs Scale up)
11
Sizing: le dimensioni contano (2/2)
Il dimensionamento può essere un problema ma… per fortuna ci
aiuta VMware!
vROps Sizing Calculator - https://kb.vmware.com/kb/2130551
12
Quali adapter abilitare?
Prima di completare il sizing: quali e quante istanze abilitare tra gli
adapters installati di default?
• vCenter Adapter
• vCenter Python Adapter
• EndPoint Operations (EPOps)
Influenza il numero di oggetti osservare e metriche da ingerire
Installeremo anche adapter di terze parti?
13
Loadbalancing e certificati
La GUI è accessibile da tutti i nodi:
• Meglio accedere tramite URL del servizio
• Consigliabile metterere i nodi dietro un LoadBalancer
• Non è un vero loadbalancing, ma più un “redirect”
Certificati SSL:
• Raramente si sostituisce il Self Signed, ma sarebbe “buona pratica” (non solo
riguardo vROPs)
• Creare un Certificato PEM col nome del servizio e un SAN per ogni nodo.
Suggerimento: riservare FQDN e indirizzi IP anche per possibili nuovi nodi
future ed inserirli come SAN nel certificato (si evita di dover sostituire il
certificato ad ogni aggiunta di un nuovo nodo)
• Il certificato caricato sul Master Node viene automaticamente propagato ad
ogni altro nodo (inclusi nodi aggiunti in seguito)
Guida ai LB: https://goo.gl/IxOshU
SSL Certs HowTo: https://goo.gl/C8DIy5
14
Estendibilità: non solo Virtual Machines
vROps può essere esteso per
collezionare e analizzare metriche da
altre tipologie di oggetti grazie ai
Management Packs
• Sviluppati da VMware o da terze parti
• Gratuiti o a pagamento
• Forniscono:
• Integrazione con altre soluzioni Vmware (vRA,
vCO, NSX etc.)
• Visibilità end-to-end verso altre componenti
infrastrutturali (Server, Storage, Network etc.)
• Integrazione con applicativi (SAP, MSSQL, Active
Directory, Postgres, Sharepoint, IBM DB2, Oracle
WebLogic etc.)
https://solutionexchange.vmware.com
15
Day 2 (vR)Ops
Occorrono almeno 4 settimane per avere dati attendibili (learning)
Le policy di default vanno tarate a “misura di organizzazione”
Le dashboard di default non coprono tutti gli scenari
La curva di apprendimento è ripida (prodotto potente ma
complesso)
Si tende (sbagliando!!!) a tornare al vCenter per fare
troubleshooting veloce
Vale la pena investire tempo nello studio e nella customizzazione di
vROps
16
Risorse utili
Il mio blog (The vGeek): http://blog.vgeek.it/
Simon Eady (Definit IT): http://www.definit.co.uk/
Sunny Dua (vXpress): http://vxpresss.blogspot.com
Simon’s & Sunny’s webinar series:
http://vxpresss.blogspot.com/2016/03/vrops-webinar-series-2016-
webinar.html
Documentazione ufficiale:
https://www.vmware.com/support/pubs/vrealize-operations-
manager-pubs.html
17
Q & A
Domande?
Top Related