RAC su macchine virtuali: ma ha senso?

Leggo volentieri da Techblast che Oracle ha certificato RAC su macchine virtuali Oracle VM.

Avere un cluster su macchine virtuali va un po' contro l'idea di alta affidabilità insita nel concetto di cluster.

La parte interessante nel documento Oracle è ovviamente l'architettura. E le chicche non mancano.

In sintesi l'architettura è spiegata dall'immagine seguente:
È evidente come la virtualizzazione venga utilizzata per ospitare più nodi virtuali (di cluster diversi) su un solo server fisico, ma il meccanismo di alta affidabilità viene conservato poichè ogni nodo di uno stesso database cluster risiede su un server fisico diverso.

Lo storage condiviso di RAC viene gestito in domain0:
Il multipathing viene utilizzato solamente sul percorso fisico dei dati da e verso i dischi, non su quello virtuale da domain0 ai domini virtuali.

Analogamente, le interfacce di rete sono in bond solo sulle porte fisiche, mentre i bridge virtuali di xenbr0 e xenbr1, sempre in domain0, sono rispettivamente la rete pubblica e la rete privata del RAC.
Essendo le istanze del RAC su nodi fisici differenti, anche per la comunicazione su rete privata si passa da rete fisica; ciò non è necessario invece nel caso di nodi sullo stesso server, che comunicherebbero direttamente attraverso il bridge 1; ma questa non è assolutamente una configurazione ragionevole per un ambiente HA.

Date le premesse del documento Oracle, sotto quest'ottica la soluzione RAC su macchine virtuali diventa tutt'altro che insensata in vari ambienti, soprattutto per consolidare server e sfruttare al massimo la potenza di elaborazione dei server attuali, facendo economia di scala.