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?