VMUGIT Meeting a Roma - 26 settembre 2016

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17
Q & A
Domande?