VHD files op SMB mount

[detim]

Hallo,

Voor een project heb ik 2 Freenas servers die naar elkaar repliceren om zo een redelijk redundante storage omgeving te creëren.

Normaal gebruik ik Proxmox en mount ik via NFS de storage.

In dit geval moet er Hyper-V gebruikt worden.
Het beste zou natuurlijk zijn iscsi, maar dit voegt naar mijn idee wat meer complexiteit toe en de toegang tot het VHD bestand vanuit andere apparaten is minder gemakkelijk te krijgen. Met NFS (en smb) kan ik gewoon het VHD bestand elders heen kopiëren en kan ik doen wat ik wil.

Een alternatief zou zijn om het met hyper-V en SMB te doen.
Heeft iemand hier ervaringen mee? Is dit een beetje snel en stabiel?
Heb het in test wel een paar keer draaiend gehad zonder gekke problemen.
Binnen hyper-v komt er geen high availibility of iets dergelijks.

[MAX3400]

Lastig. Hyper-V houdt niet zo van replicatie op storage niveau tenzij je gebruikt maakt van een multipath en cluster shared volumes.

Ander nadeel, met sommige replicatie: als je op storage A een VM hebt en, ervanuitgaande dat je hele storage netjes repliceert en je start de VM dan van storage B, is er soms kans dat de GUID van de disks "ander" wordt. Oftewel, 3 VHD's kunnen dan "random" gekoppeld worden met alle gevolgen van dien.

Alternatief, maar dan mik ik je use-case een beetje in de vuilnisbak; beide storage/volumes "apart" koppelen aan je hypervisor (ongeacht je protocol). Hierdoor dus geen enkele vorm van HA maar dan kan je wel op 1 host/management een VM-migration uitvoeren naar de andere storage.

[detim]

MAX3400 schreef op vrijdag 31 augustus 2018 @ 20:35:
Lastig. Hyper-V houdt niet zo van replicatie op storage niveau tenzij je gebruikt maakt van een multipath en cluster shared volumes.

Ander nadeel, met sommige replicatie: als je op storage A een VM hebt en, ervanuitgaande dat je hele storage netjes repliceert en je start de VM dan van storage B, is er soms kans dat de GUID van de disks "ander" wordt. Oftewel, 3 VHD's kunnen dan "random" gekoppeld worden met alle gevolgen van dien.

Alternatief, maar dan mik ik je use-case een beetje in de vuilnisbak; beide storage/volumes "apart" koppelen aan je hypervisor (ongeacht je protocol). Hierdoor dus geen enkele vorm van HA maar dan kan je wel op 1 host/management een VM-migration uitvoeren naar de andere storage.

Thanks voor je antwoord!

Mijn setup is eigenlijk het volgende.

1 live storage bak gekoppeld aan de hypervisor
1 standby storage bak, replicatie elke 5 minuten

Als de live storage omvalt koppel ik hem handmatig aan een hypervisor en mis ik maximaal 5 minuten.
Dus de problemen die jij schetst zijn denk ik niet aan de orde?

[MAX3400]

Je repliceert dus eigenlijk niets? Of heb je dit al getest/werkend? En "hoe" heb je replicatie ingeregeld op FreeNAS (ook omdat ik FreeNAS niet ken maar dat terzijde; storage/protocollen zijn universeel).

Sowieso adviseert Microsoft om virtual disks van een running VM niet aan te raken op een andere manier dan door Hyper-V (system / accounts / services). Niet in de laatste plaats omdat jouw interval van 5 minuten niets zegt over de inhoud van de disk. Anders gezegd; een disk met bepaald type inhoud, zeg even 512MB, kan je zonder problemen in RAM van een machine laden (lekker cachen bijvoorbeeld). 6 uur lang verandert de data in het geheugen en dan valt de VM om. Hoeveel uur data mis je dan?

Verder, maar dan mis ik mogelijk voldoende info: snapshots, differencing disks, VSV-files en overige zaken kunnen ook niet tegen "5 minuten kopieren" want deze zaken worden pas geconsolideerd / unlocked / "pointer updates verwerkt" als een VM netjes wordt afgesloten. Netjes afsluiten kan je vergeten als je live storage omvalt. Ook dan heb je netjes "outdated" differencing disks en snapshots op je standby storage staan.

Let wel: dit is hoe ik vanuit het perspectief van Hyper-V kijk. Zoals gezegd; ik ken de exacte manieren niet hoe FreeNAS iets "repliceert" maar allicht zou je mijn suggesties/voorbeelden eens kunnen proberen? Zoals data 6 uur in RAM houden en dan je storage uit de muur trekken? Of een VM met 1 differencing disk en 4 snapshots proberen te reverten naar "active - 1" nadat je de eerste storage uit de muur trekt?

[The Eagle]

Ik denk dat je even je servers die op die storage logisch uit elkaar moet trekken. Als in: een VM heeft meerdere disks (VHD's) met verschillende typen data. Een disk is OS, tweede evt swap en op de derde staat je applicatiesoftware.
OS disks en VM zelf snapshot je om het half uur en die zet je over. Applicatiesoftware hou je wel in sync, die kan er nl veel beter tegen. Een evt DB hou je uiteraard los, die kunnen vrij slecht tegen vm spul dat mee t in te moeten breken op in gebruik zijnde files

[Hero of Time]

Als alternatief, je weet dat je met Linux en BSD ook gewoon bestanden kan aanbieden als iSCSI? Je maakt dan met dd een 'image' van zeg 30 GB. Die geef je dan aan Hyper-V om als direct beschrijfbare VM disk te gebruiken. Je kan dan op de fileserver gebruik maken van snapshotting en replicatie waarbij het image in tact blijft. Je zit dan in het ergste geval met een corrupt file system in het image als de connectie spontaan wegvalt of je moet overschakelen op je replica als het net op een ongelukkig moment gebeurt. Maar dat heb je met SMB ook. Performance technisch gezien zal je met iSCSI het wat beter kunnen doen dan aanbieden via SMB.

[Question Mark]

Hero of Time schreef op vrijdag 31 augustus 2018 @ 23:01:
Performance technisch gezien zal je met iSCSI het wat beter kunnen doen dan aanbieden via SMB.

Dat laatste betwijfel ik. SMB 3.0 kent veel grote voordelen ten opzichte van voorgaande versies.

https://searchservervirtu...mp-on-the-SMB-3-bandwagon

detim schreef op vrijdag 31 augustus 2018 @ 20:25:
Een alternatief zou zijn om het met hyper-V en SMB te doen.
Heeft iemand hier ervaringen mee? Is dit een beetje snel en stabiel?
Heb het in test wel een paar keer draaiend gehad zonder gekke problemen.
Binnen hyper-v komt er geen high availibility of iets dergelijks.

Wat bedoel je met deze alinea? Je wilt ook wel een redudante storage aanbieden vanaf Hyper-V, maar met als eis dat er geen HA-features vanaf Hyper-V ingezet mogen gaan worden?

Daarnaast ben ik even benieuwd wat nu je einddoel is. Wat wil je gaan aanbieden vanaf die redudante storage? Als dat puur VHD's zijn, voor dezelfde Hyper-V omgeving, dan zou ik de oplossing zo plat mogelijk willen houden. Een Hyperconverged oplossing dus... Redudant, snel en geen 3rd-party oplossingen nodig maar volledig vanuit Windows/Hyper-V aangeboden.

Niks mis met 3rd-party oplossingen, maar het is wel weer een extra laag te beheren. Daarnaast loop je kans dat MS en FreeNas naar elkaar gaan lopen wijzen bij issue's. Voor een hobby-project minder spannend, voor een produktie omgeving moet je dit soort situaties absoluut gaan voorkomen.

[Hero of Time]

Question Mark schreef op zaterdag 1 september 2018 @ 12:33:
[...]

Dat laatste betwijfel ik. SMB 3.0 kent veel grote voordelen ten opzichte van voorgaande versies.

https://searchservervirtu...mp-on-the-SMB-3-bandwagon

Hmm, mijn gedachtegang was meer dat je de overhead van vhdx bestand over een file-based sharing protocol overslaat en zo wat directer je disks in freenas (of wat voor file server je draait) benadert. Afhankelijk hoe Hyper-V data wegschrijft in een virtuele disk kan het block based sneller zijn dan file based.
Je zou dan zelfs nog het file system van de file server weg kunnen laten en raw partities aanbieden via iSCSI.