Network storage in VM's - beste / snelste methode?

[iGadget]

In mijn huidige setup wil ik bestanden die op mijn NAS staan toegankelijk maken voor mijn VM's. De vraag is alleen, wat is de beste / snelste manier?

Fysiek ziet het plaatje er zo uit:

[NAS] <-directe gigabit verbinding-> [server met KVM] <-> [switch] <-> [clients]

De server is een Dell PowerEdge dual Xeon machine met 8GB geheugen, met daarop Ubuntu Server 12.04 als hypervisor. De eerste LAN poort gaat naar de switch, de 2e heeft een directe verbinding met de NAS.
Op dit moment maken de VM's nog gebruik van de lokale storage van de server, maar deze is beperkt (en traag). Voor systeembestanden niet zo'n punt, maar voor user data wil ik toch echt de capaciteiten van de NAS gaan gebruiken.

- Optie 1 zou IMHO zijn om vanaf de hypervisor de boel via NFS te mounten en deze mappen vervolgens weer beschikbaar stellen aan de VM's.
- Optie 2 zou zijn om dit niet vanuit de hypervisor, maar vanuit elke VM afzonderlijk te doen.

Welke van deze opties zou aan te raden zijn? Of is er nog een beter scenario waar ik nog niet aan gedacht heb?

Nog een kleine toelichting waarom ik dit zo wil - ik ben bijvoorbeeld aan het spelen met OwnCloud als vervanger voor Ubuntu One (en DropBox en consorten, al gebruik ik die nauwelijks). Mijn NAS (QNAP TS-639) is niet snel genoeg om dit zelf te draaien en bovendien vertrouw ik het niet om een QNAP rechtstreeks aan het internet te hangen (wat op termijn wel de bedoeling is). Dit omdat ze lang niet altijd even snel zijn met hun beveiligingsupdates.

Bovendien is de PowerEdge vele malen krachtiger, dus dat leek me een betere optie om dit soort grappen op uit te halen.
Met KVM kan ik dan op termijn een 2e server optuigen waardoor live migration van VM's mogelijk wordt.

Alle feedback meer dan welkom

[TVH7]

Okey, Maar waar is het snelheidsprobleem dan? Voor Owncloud heb je opzich niet heel erg veel nodig omdat als je van buitenaf gaat werken toch gelimiteerd bent aan je upload een simpele 7200k schijf of een dell 10k schijf moet gewoon goed zijn voor 1 of 2 vm's met owncloud. Ik merk verder ook dat Owncloud niet het stabielste en snelste is met vooral grote bestanden krijg je vaak problemen. Ik dacht eerst dat dat aan de storage array lag maar dat was het dus niet. Als je echter vm's gaat draaien die niet stroperig moeten zijn zou ik gaan kijken naar een goede raid controller met een aantal schijven en een ssd cache array. Of gewoon een array ssd's en die gebruiken voor je boot drives. IOPS zijn hier dan belangerijk.

[ Voor 21% gewijzigd door TVH7 op 15-05-2014 12:07 ]

[Ximon]

Daarnaast zou ik zeggen dat het in principe sneller is om de storage aan de hypervisor vast te knopen in plaats van aan de guests. Als je dat niet zou doen, dan moet alle IO door de hypervisor vertaald worden naast de gebruikelijke verwerking door het host- of guest OS. Er zijn situaties waarin dit evengoed handig is (bijvoorbeeld als je Netapp gebruikt i.c.m. sommige Snapmanagers) maar dat is dat voor zover ik weet nooit vanwege performanceoverwegingen.

Een andere reden zou kunnen zijn dat het bijvoorbeeld niet mogelijk is een clustered file system te gebruiken (zie Wikipedia) en je live migration wil doen terwijl je een bepaald volume met een server wilt mee migreren. Ik kan me alleen geen voorbeeld hiervan bedenken: als je bijvoorbeeld je LUNs als iSCSI op beide hosts beschikbaar maakt bereik je dit ook.

Naast de performance lijkt het me ook handiger om de storage op hostniveau te beheren in plaats van op guestniveau: je kan dan een of enkele pools met storage opknippen en flexibel aanbieden aan de guests. Als je de LUNs direct in de guests mount moet je ook daarmee gaan zitten emmeren als er een disk groter of kleiner moet.

Nog een laatste opmerking over de QNAP: vertrouw dat ding alleen voor storage en voer inderdaad andere geinige appjes vooral niet op dat ding uit. Sowieso kan dan bijvoorbeeld zo'n app de performance van je storage beinvloeden en daarnaast zijn de gewone versies van die software meestal stabieler, sneller of uitgebreider dan de QNAP versie.