Quando progettate una nuova installazione di PernixData, è possibile utilizzare un cluster in cui non tutti i server ESXi sono dotati di memoria Flash (sia essa su scheda PCIe o su SSD); tuttavia, è vi sono alcune accortezze da rispettare, sia in fase di installazione che di utilizzo.
Installazione
Nel mio laboratorio possiedo ad oggi 3 server ESXi, ma solo due di questi sono dotati di schede Flash (un paio di Fusion-IO ioDrive 320Gb per la precisione), mentre il terzo server non possiede nessuna memoria Flash, nemmeno un semplice SSD.
Nell’installare PernixData quindi, inizialmente avevo installato le host extensions sui primi due server, e ultimato la configurazione del mio Cluster FVP:
Con questa configurazione, è già possibile attivare la cache di una virtual machine ospitata sui server 1 e 2 in modalità write-through (accelerazione delle letture), ma non è possibile abilitare l’accelerazione write-back:
La soluzione è installare le host extensions su TUTTI i server ESXi del cluster, anche quelli dove non è presente una memoria Flash. Ho quindi installato PernixData anche sul mio terzo server, e anche se Pernix continua a segnalare un problema su questo server, stavolta relativo alla mancaza di Flash Device:
adesso è possibile attivare la modalità Write Back:
Da notare come sia possibile, ovviamente, avere unicamente la copia locale della cache e al massimo 1 copia remota, essendo solo 2 i server con a disposizione una mamoria Flash.
Posso spostare la VM sul server senza Flash?
La virtual machine è in esecuzione sul server 2, in cui è presente la scheda Fusion-IO, e Pernix mi conferma che sto effettivamente utilizzando l’accelerazione Write Back:
Dal momento che il cluster utilizza DRS in modalità automatica, la domanda principale che ci si può porre è ovviamente: “Posso fare vmotion di questa virtual machine sul server senza memoria Flash? E come si comporterà Pernix?”. Per rispondere a questa domanda, ho momentaneamente configurato DRS in modalità manuale, per essere certo che la virtual machine rimanesse sul server ESXi che desideravo, e ho quindi avviato un workload con JetStress per simulare 200 utenti di Exchange Server (200 MB e 10 iops per casella). Immediatamente, PernixData ha iniziato a fare il suo lavoro, accelerando il database Exchange. Alle ore 0.43 (il punto indicato dalla riga verticale in rosso nel grafico che segue), avvio la vmotion dal server 2 (con memoria Flash) verso il server 3 (senza memoria Flash). La migrazione avviene senza il minimo sussulto o errore, e come era prevedibile Pernix smette di accelerare la virtual machine:
Per un breve momento, lo stato della cache è “Replay Required or in Progress”:
per poi passare definitivamente in “write Through”, anche se ovviamente non viene accelerato nulla, non essendo presente nessuna memoria Flash.
notate come il contenuto della cache sia ovviamente completamente remoto, essendo quanto contenuto nel server ESXi 2. L’ultimissima prova, è stata riportare la virtual machine nuovamente sul server 2; Pernix ha riconfigurato immediatamente la cache in “Write Back” e ha ricominciato ad accelerare le attività su disco.
Note finali
Due cose sono emerse da queste prove.
Da un punto di vista tecnico, è possibile utilizzare PernixData, anche in modalità write-back, in cluster dove non tutti i server possiedono memorie Flash; bisogna solo ricordarsi di installare le host extensions su tutti i server del cluster. Tutte le attività che coinvolgono vMotion funzionano perfettamente, quindi anche DRS, e Pernix adegua il suo comportamento automaticamente in base alle condizioni del server su cui si trova ad agire.
Da un punto di vista architetturale, mi sento invece di sconsigliare una configurazione di questo tipo: le prestazioni di una virtual machine fluttuano enormemente, con tutte le conseguenze del caso. Se doveste avere necessità di utilizzare le memorie Flash solo in alcuni dei server presenti, magari perchè il budget permetteva di acquistare solo poche schede Flash oppure perchè si deve accelerare solo una virtual machine, è consigliabile attivare delle specifiche regole DRS per fare in modo che la virtual machine resti sui server dotati di memoria Flash e non venga migrata.