Shared storage voor een Hyper-V cluster (ergo HA)

[HyperBart]

Ik ben met een project op mijn stage bezig.
We gebruiken hier op het bedrijf voor HA-solutions vrijwel altijd de oplossingen van VMWare (ESX(i) + vSphere/vCenter) om dit te bekomen.

Nu is mijn project getiteld als: High Availability op een Hyper-V Platform door middel van Clustering .

Wegens gebrek aan een tweede fysieke host virtualiseer ik mijn Hyper-V hosts op een ESX-host (opmerkingen daarover graag als dat ook nog problemen met betrekking tot Intel VT kan leveren).

Op die ESX host draai ik dus mijn zogenaamde (2) "fysieke Hyper-V hosts" en een OpenFiler besturingssysteem. Dat OF-systeem was bedoeld om een iSCSI target aan te maken. So far so good, maar via OF kan je alleen iSCSI targets aanmaken die gebaseerd zijn op IET en dat ondersteunt geen "persistent reservation commands" wat benodigd is om meerdere Windows-servers gelijktijdig toegang te geven tot één hetzelfde iSCSI target.

Ik heb me nu al suf gezocht, maar ik vind geen oplossing (moet niet noodzakelijk via openfiler zijn) waardoor ik shared storage kan verkrijgen of ik kan geen enkele manier bedenken hoe ik ervoor kan zorgen dat ik HA kan bereiken via een Hyper-V platform.

Heb ik gewoon te weinig hardware? Wat kan ik nog doen? Want op dit moment zit ik hier maar oplossing voor te zoeken maar vind er niets (gratis) van.

[Zwelgje]

http://www.rocketdivision.com/download_starwind.html

gebruik ik altijd voor hyper-v testomgevingen

[Krypt]

Volgens mij heb je dan een cluster based filesystem nodig.

Collega van mij is bezig geweest ermee; maar kreeg het ook niet fatsoenlijk voor elkaar. Hij kreeg erg snel corruptie en was zijn bestanden kwijt na een flinke loadtest (copy/move & delete).

[Zwelgje]

Krypt schreef op maandag 22 maart 2010 @ 16:41:
Volgens mij heb je dan een cluster based filesystem nodig.

Collega van mij is bezig geweest ermee; maar kreeg het ook niet fatsoenlijk voor elkaar. Hij kreeg erg snel corruptie en was zijn bestanden kwijt na een flinke loadtest (copy/move & delete).

R2 heeft een functionaliteit in de vorm van 'CSV' (clustered shared volumes) welke dit probleem oplost

file/move/deletes zouden nooit corrupt mogen raken omdat dit via een 'master node' gaat welke verantwoordelijke is voor veranderingen op het CSV.

howto: http://blogs.msdn.com/clu...e/2009/02/19/9433146.aspx

[ Voor 5% gewijzigd door Zwelgje op 22-03-2010 18:49 ]

[downtime]

HyperBart schreef op maandag 22 maart 2010 @ 16:17:
Ik ben met een project op mijn stage bezig.
Ik heb me nu al suf gezocht, maar ik vind geen oplossing (moet niet noodzakelijk via openfiler zijn) waardoor ik shared storage kan verkrijgen of ik kan geen enkele manier bedenken hoe ik ervoor kan zorgen dat ik HA kan bereiken via een Hyper-V platform.

Kun je hier niks mee?

[MAX3400]

Of dit speeltje van NetApp; moet er alleen wel bij zeggen dat het niet de simpelse oplossing misschien is voor je vraagstelling...

[HyperBart]

Powershell schreef op maandag 22 maart 2010 @ 16:34:
http://www.rocketdivision.com/download_starwind.html

gebruik ik altijd voor hyper-v testomgevingen

Ik heb nu dat target aangemaakt, en toegevoegd als een schijf met de iSCSI initiator van W2K8, maar als ik nu files maak op die schijf op de ene host, en ik ga dan naar de andere waar dat iscsi target ook is gemapped, komen die files niet tevoorschijn.

Hoe voeg jij in een Hyper-V cluster dan je gemeenschappelijke storage toe? Ik veronderstel dat als je HA wilt bereiken, dat de hosts in de cluster dan toch allemaal toegang moeten hebben tot de vmdk's van alle andere hosts?

[MAX3400]

Misschien kan je op http://communities.vmware.com/thread/258403?tstart=0 wat meer vinden over CSV op VMware.

Trouwens, je hebt het over hosts; bedoel je niet je guests die je binnen VMware hebt geconfigureerd?

[Question Mark]

MAX3400 schreef op maandag 22 maart 2010 @ 22:46:
Of dit speeltje van NetApp; moet er alleen wel bij zeggen dat het niet de simpelse oplossing misschien is voor je vraagstelling...

Die is alleen als advanced partner of customer te krijgen. Bovendien heeft de ontapp simulator een beperking op aantal en grootte van je disken.

[Zwelgje]

HyperBart schreef op woensdag 24 maart 2010 @ 10:24:
[...]

Ik heb nu dat target aangemaakt, en toegevoegd als een schijf met de iSCSI initiator van W2K8, maar als ik nu files maak op die schijf op de ene host, en ik ga dan naar de andere waar dat iscsi target ook is gemapped, komen die files niet tevoorschijn.

Hoe voeg jij in een Hyper-V cluster dan je gemeenschappelijke storage toe? Ik veronderstel dat als je HA wilt bereiken, dat de hosts in de cluster dan toch allemaal toegang moeten hebben tot de vmdk's van alle andere hosts?

vmdk's hyper-v gebruikt vhd's..

en dat linkje in mijn reply omvat precies wat jij wilt, een complete howto hoe een CSV volume aan te maken binnen de clusterconfiguration snapin

[MAX3400]

Powershell schreef op woensdag 24 maart 2010 @ 10:39:
[...]


vmdk's hyper-v gebruikt vhd's..

Ja, maar volgens mij is de host een ESX-bak, daarbinnen zijn VMDK's gemaakt van Hyper-V-hosts en daarbinnen wordt er weer gespeeld met VHD-guests.

Goedemorgen trouwens...

[ Voor 6% gewijzigd door MAX3400 op 24-03-2010 10:44 ]

[HyperBart]

Voila, MAX3400 heeft het door. maar de Hyper-V rol kan niet toegevoegd worden op die VM's die ik draai op de ESX-host, want de virtuele cpu's die gepresenteerd worden aan de VM's ondersteunen geen VT-X en dat is blijkbaar nodig om die Hyper-V rol toe te voegen (redelijk logisch imho).

Anyway, ik moet nu wachten op een tweede fysieke host... En dan ga ik het wat degelijker aanpakken... (de Hyper-V hosts effectief installeren op fysieke machines)

Powershell schreef op woensdag 24 maart 2010 @ 10:39:
[...]


vmdk's hyper-v gebruikt vhd's..

Idd, ik bedoelde VHD's

en dat linkje in mijn reply omvat precies wat jij wilt, een complete howto hoe een CSV volume aan te maken binnen de clusterconfiguration snapin

Pardon, dat heb ik gemist, ik kijk het in de loop van de dag nog even na...

[ Voor 3% gewijzigd door HyperBart op 24-03-2010 11:05 ]

[Zwelgje]

MAX3400 schreef op woensdag 24 maart 2010 @ 10:44:
[...]

Ja, maar volgens mij is de host een ESX-bak, daarbinnen zijn VMDK's gemaakt van Hyper-V-hosts en daarbinnen wordt er weer gespeeld met VHD-guests.

Goedemorgen trouwens...

nou dan kan ie zijn experiment wel staken, hyper-v als guest in ESX werkt niet

wat je wel kan doen is de gratis hyper-v server downloaden die kan je we installeren als guest in vmware inclusief de hyper-v role alleen kan je dan geen guests starten

[ Voor 18% gewijzigd door Zwelgje op 24-03-2010 11:10 ]

[HyperBart]

Powershell schreef op woensdag 24 maart 2010 @ 11:09:
[...]
wat je wel kan doen is de gratis hyper-v server downloaden die kan je we installeren als guest in vmware inclusief de hyper-v role alleen kan je dan geen guests starten

Is wel moeilijk om dan HA aan te tonen he

[Zwelgje]

HyperBart schreef op woensdag 24 maart 2010 @ 11:19:
[...]

Is wel moeilijk om dan HA aan te tonen he

mja je kan dan wel de clusterconfig bouwen en de hyper-v interface verkennen.

met XenServer kan het iig wel in een vm, inclusief xenmotion...mgoed dat gebruik je niet

* Zwelgje is XenServer fanboy

[HyperBart]

OK, het project is nu wat geupdated: ik krijg de beschikking over 2 ML 110 G5's, beide bijna identieke CPU's en 4GB-5GB geheugen.

Voor de storage krijg ik een NAS waar ik normaal en iSCSI-target op kan aanmaken.

@Powershell: heb ik dan genoeg om een gemeenschappelijk toegankelijke storage te hebben waar beide nodes toegang toe hebben met die CSV? Want ik lees bij de http://technet.microsoft..../cc732035%28WS.10%29.aspx dat er toch weer SCSI 3 features nodig zijn...

enne jongens, bedankt... Want ik kzag het hier even niet meer zitten...

[ Voor 7% gewijzigd door HyperBart op 24-03-2010 15:37 ]

[Zwelgje]

HyperBart schreef op woensdag 24 maart 2010 @ 15:37:
OK, het project is nu wat geupdated: ik krijg de beschikking over 2 ML 110 G5's, beide bijna identieke CPU's en 4GB-5GB geheugen.

Voor de storage krijg ik een NAS waar ik normaal en iSCSI-target op kan aanmaken.

@Powershell: heb ik dan genoeg om een gemeenschappelijk toegankelijke storage te hebben waar beide nodes toegang toe hebben met die CSV? Want ik lees bij de http://technet.microsoft..../cc732035%28WS.10%29.aspx dat er toch weer SCSI 3 features nodig zijn...

enne jongens, bedankt... Want ik kzag het hier even niet meer zitten...

dat ding moet persistent reservations ondersteunen... worstcase pak je een XP/vista/7/2003/2008 bak en zet je daar die iscsi software op uit de link die ik je eerder mailde die werkt sowieso

[HyperBart]

Hmm, even onderzoeken dan, bedankt...

Maar even nu een schets, want door een gesprek met de sales-manager is er even wat onduidelijkheid:

Het is toch zo, dat je twee nodes hebt in de cluster, die allemaal toegang hebben tot dezelfde storage. Die nodes (node 1 en node 2) draaien allebei twee verschillende VM's, op VM A draait bv de Active Directory op VM B draait een SQL server.
Iemand komt binnen en trekt de stekker uit van de node waar VM B op draait, gevolg: VM B ligt er uit, dan is het HA-principe hier toch dat node 1 via de heartbeat voelt dat node 2 er uit ligt en dus VM B op zijn eigen hardware terug opstart, of zit ik ergens fout?

[LuckY]

Ligt eraan wat voor je gebruikt, active active of active passive
Echter, wat als iemand de stekker van je NAS eruit trekt ?

[HyperBart]

LuckY schreef op woensdag 24 maart 2010 @ 16:09:
Ligt eraan wat voor je gebruikt, active active of active passive

say what?
ah, active active is eigenlijk het dubbel draaien van servers?
active passive is het failoveren, dus rebooten van een vm die uitgevallen is doordat de node waarop die vm draaide er uit ligt...

Echter, wat als iemand de stekker van je NAS eruit trekt ?

Ja, dan ben ik genegerd , dat had ik ook al opgemerkt. Maar dat is veronderstel ik altijd bij HA-oplossingen dat je je storage ook redundant uitvoert, of niet ? Dit product dient eigenlijk om eens de HA van Hyper-V aan te tonen, dat dat ook wel een beetje degelijk marcheert en dat het relatief makkelijk is op te stellen...

[ Voor 14% gewijzigd door HyperBart op 24-03-2010 16:19 ]

[MAX3400]

HA is overrated...

HA kan je zo gek maken als je zelf wil. En totdat voor een HA-oplossing geen budget bekend is, moet je uitgaan van het ergste, zoals de voorbeelden van LuckY waaronder een stekker die ergens uit wordt getrokken. En op een gegeven moment kom je op een break-even punt waar HA op 1 lokatie duurder wordt dan "simpeler" HA op een gemirrorde lokatie (al dan niet passief of aktief).

[Zwelgje]

HyperBart schreef op woensdag 24 maart 2010 @ 16:08:
Hmm, even onderzoeken dan, bedankt...

Maar even nu een schets, want door een gesprek met de sales-manager is er even wat onduidelijkheid:

Het is toch zo, dat je twee nodes hebt in de cluster, die allemaal toegang hebben tot dezelfde storage. Die nodes (node 1 en node 2) draaien allebei twee verschillende VM's, op VM A draait bv de Active Directory op VM B draait een SQL server.
Iemand komt binnen en trekt de stekker uit van de node waar VM B op draait, gevolg: VM B ligt er uit, dan is het HA-principe hier toch dat node 1 via de heartbeat voelt dat node 2 er uit ligt en dus VM B op zijn eigen hardware terug opstart, of zit ik ergens fout?

that's the idea ja en zo werkt het ook met hyper-v (clustering in windows in het algmeen)

[MAX3400]

HyperBart schreef op woensdag 24 maart 2010 @ 16:08:
Iemand komt binnen en trekt de stekker uit van de node waar VM B op draait, gevolg: VM B ligt er uit, dan is het HA-principe hier toch dat node 1 via de heartbeat voelt dat node 2 er uit ligt en dus VM B op zijn eigen hardware terug opstart, of zit ik ergens fout?

Ergens mis ik nog iets; je RAM-state is bijvoorbeeld nooit gegarandeerd. Dus met een beetje ongeluk moet je dus VM B van grond af opnieuw opstarten omdat een SQL-bak rustig zijn hele geheugen voltrapt met cached data. Dat heeft dan ook weer gevolgen voor, bijvoorbeeld, de recovery-mode die je instelt op een virtuele SQL-instance.

[HyperBart]

MAX3400 schreef op woensdag 24 maart 2010 @ 16:27:
[...]

Ergens mis ik nog iets; je RAM-state is bijvoorbeeld nooit gegarandeerd. Dus met een beetje ongeluk moet je dus VM B van grond af opnieuw opstarten omdat een SQL-bak rustig zijn hele geheugen voltrapt met cached data. Dat heeft dan ook weer gevolgen voor, bijvoorbeeld, de recovery-mode die je instelt op een virtuele SQL-instance.

Als de stroom uitgetrokken wordt dan is de RAM toch altijd leeg, heet hetgeen wat jij wilt bereiken (namelijk geen downtime en geen verlies) niet gewoon fault tolerance? Als in: ik draai machines tegelijkertijd op twee hosts?

HA is voor zover ik weet: cluster van fysieke machines, een van de fysieke machines flikkert er uit, de vm's die er op draaien dus ook, dus andere fysieke machines in de cluster starten automagisch de uitgevallen vm's op...

Correct me if i'm wrong...

edit: mss was het sql-vm voorbeeldje een slecht voorbeeld, want dat is nu net een speciaal geval, maar neem dan bijv een mailserver.

[ Voor 6% gewijzigd door HyperBart op 24-03-2010 17:19 ]

[MAX3400]

HyperBart schreef op woensdag 24 maart 2010 @ 17:06:
[...]

Als de stroom uitgetrokken wordt dan is de RAM toch altijd leeg, heet hetgeen wat jij wilt bereiken (namelijk geen downtime) niet gewoon fault tolerance? Als in: ik draai machines tegelijkertijd op twee hosts?

Er zijn, voor zover ik dacht, mogelijkheden om de RAM-state over te hevelen. Dit is dus wel de RAM-state van de VM's en inderdaad niet van de host.

HA is voor zover ik weet: cluster van fysieke machines, een van de fysieke machines flikkert er uit, de vm's die er op draaien dus ook, dus andere fysieke machines in de cluster starten automagisch de uitgevallen vm's op...

Failover? VMotion? De bedoeling is met ESX/Hyper-V/Xen dat een machine blijft draaien en bij uitval van host A "draaiend" door host B wordt overgenomen en dus niet opnieuw opgestart. Want dan kan je natuurlijk je hele hypervisor-laag wegstrepen en overal & goedkoper, normale clustering inzetten met fysieke machines.

edit: mss was het sql-vm voorbeeldje een slecht voorbeeld, want dat is nu net een speciaal geval, maar neem dan bijv een mailserver.

Zelfde verhaal; heb je wel eens het store.exe process in de gaten gehouden op een Exchange-bak? Staat ook heerlijk te cachen.

/editje: ben er ff helemaal klaar mee vandaag. Niet met het topic maar met nadenken... Sorry...

[ Voor 15% gewijzigd door MAX3400 op 24-03-2010 17:21 ]

[HyperBart]

MAX3400 schreef op woensdag 24 maart 2010 @ 17:18:
[...]

Er zijn, voor zover ik dacht, mogelijkheden om de RAM-state over te hevelen. Dit is dus wel de RAM-state van de VM's en inderdaad niet van de host.

Lijkt mij sterk, want dat betekent dat real time of om de zoveel tijd het ram geheugen op een storage wordt gezet zodat andere nodes/hosts toegang hebben tot die gesavede ram...

Failover? VMotion? De bedoeling is met ESX/Hyper-V/Xen dat een machine blijft draaien en bij uitval van host A "draaiend" door host B wordt overgenomen en dus niet opnieuw opgestart. Want dan kan je natuurlijk je hele hypervisor-laag wegstrepen en overal & goedkoper, normale clustering inzetten met fysieke machines.

Hoe kan dat dan? Dan moet alles wat betrekking heeft tot data (= RAM en HD dus) toch ergens gemeenschappelijk staan, en RAM gaat toch te snel om bv continu op een storage te zetten zodat andere VM's dit kunnen overnemen.

Wat jij voorstelt is live migration en dat wordt gestart door een beheerder zelf. Die zogenoemde "failover" (sla me niet dood als ik hier niet de juiste termen gebruik) is vlngs mij "fault tolerance", namelijk dat een iedere bewerking op één vm ook gedaan wordt op een reserve-vm, flikkert de eerste er uit, merkt de user er niets van want de reserve-vm draait realtime mee...

Zelfde verhaal; heb je wel eens het store.exe process in de gaten gehouden op een Exchange-bak? Staat ook heerlijk te cachen.

Neen, ik heb daar nog geen ervaringen mee, maar je weet in principe wat ik bedoel, neem dan een vb naar eigen keuze wat niet zo fel aan dat caching gebeuren mee doet...

[ Voor 12% gewijzigd door HyperBart op 24-03-2010 17:27 ]

[MAX3400]

HyperBart, even terug naar de topicstart dan maar met een kleine aanpassing.

Pak 2 fysieke hosts met Hyper-V erop. Die connecten via iSCSI naar een centrale storage. Op die centrale storage staan de VHD's van de guest-machines. Op het moment dat de ene fysieke host er mee ophoudt, staan de VHD's toch op de centrale storage waar host 2 nog steeds bij kan en dus de VHD in de lucht kan houden?

Ik moet even in de documentatie duiken omtrent NVRAM i.v.m. de RAM-state van VM's.

Voor wat betreft caching: laten we aannemen dat inderdaad het RAM "verdwijnt" maar een VM wel door een andere host in de lucht wordt gehouden. Dan moet je voor verschillende server-software zoals SQL of Exchange of Oracle, een goed recovery & transaction model bedenken om data-verlies te voorkomen of in ieder geval zo ver mogelijk te beperken.

[ Voor 26% gewijzigd door MAX3400 op 24-03-2010 17:28 ]

[HyperBart]

MAX3400 schreef op woensdag 24 maart 2010 @ 17:27:
HyperBart, even terug naar de topicstart dan maar met een kleine aanpassing.

Pak 2 fysieke hosts met Hyper-V erop. Die connecten via iSCSI naar een centrale storage. Op die centrale storage staan de VHD's van de guest-machines. Op het moment dat de ene fysieke host er mee ophoudt, staan de VHD's toch op de centrale storage waar host 2 nog steeds bij kan en dus de VHD in de lucht kan houden?

Ik moet even in de documentatie duiken omtrent NVRAM i.v.m. de RAM-state van VM's.

Neen, ik heb even wat gezocht, en de lock wordt dan van die VHD afgehaald, zodat een andere machine die kan accessen en opnieuw kan opstarten...

Misschien kan powershell even scheidsrechteren? Ik weet het niet, ik probeer alleen maar mijn gedachtegang te verduidelijken, maar ik zeg absoluut niet dat die juist is he ...

[Question Mark]

MAX3400 schreef op woensdag 24 maart 2010 @ 17:18:
[...]
Failover? VMotion? De bedoeling is met ESX/Hyper-V/Xen dat een machine blijft draaien en bij uitval van host A "draaiend" door host B wordt overgenomen en dus niet opnieuw opgestart.

Daar heb je dus fault-tolerant voor nodig. De HA opties van ESX/Hyper-V/Xenserver zorgen er alleen voor dat een VM weer opgestart wordt op een andere node. Vergeet verder ook niet dat er eerst een bepaalde time-out plaatsvind voordat een HA-overname plaatsvind. De nodes in het cluster (ongeacht welke hypervisor dit is) moeten wel zeker weten dat een Host down is, en dat er niet toevallig een klein netwerkhikje is.

Voordat failover plaatsvind, gaat er vaak nog wel een kleine minuut overheen.

Want dan kan je natuurlijk je hele hypervisor-laag wegstrepen en overal & goedkoper, normale clustering inzetten met fysieke machines.

Niet elke applicatie is te clusteren, bovendien is dit licentietechnisch vaak duurder vanwege de benodigde Enterprise licenties.

[ Voor 18% gewijzigd door Question Mark op 24-03-2010 17:34 ]

[downtime]

HyperBart schreef op maandag 22 maart 2010 @ 16:17:
Ik heb me nu al suf gezocht, maar ik vind geen oplossing (moet niet noodzakelijk via openfiler zijn) waardoor ik shared storage kan verkrijgen of ik kan geen enkele manier bedenken hoe ik ervoor kan zorgen dat ik HA kan bereiken via een Hyper-V platform.

Ik denk dat je verkeerd denkt. Je moet niet je servers hoog-beschikbaar maken maar de applicaties en de diensten die ze leveren. Dat doe je via (vormen van) load-balancing en fail-over clustering. Daarbij vertrouw je niet op een hoog beschikbare server maar een applicatie die zich daarvoor leent.

Een hoog-beschikbaar virtualisatie platform levert zijn hoog-beschikbaarheid doordat je werkende servers via live-migration (of hoe het ook heet) naar een andere fysieke node overbrengt zodat de vorige fysieke node "down" kan voor bijvoorbeeld hardware onderhoud. Dat is dus een gepland en gecontroleerd proces. Hoog-beschikbare virtualisatie levert je geen volledige oplossing voor ongeplande events.

[HyperBart]

downtime schreef op woensdag 24 maart 2010 @ 20:28:
[...]

Ik denk dat je verkeerd denkt. Je moet niet je servers hoog-beschikbaar maken maar de applicaties en de diensten die ze leveren. Dat doe je via (vormen van) load-balancing en fail-over clustering. Daarbij vertrouw je niet op een hoog beschikbare server maar een applicatie die zich daarvoor leent.

Akkoord, dat is altijd het probleem geweest bij het HA-principe, je VM's blijven wel draaien (of worden terug opnieuw opgestart, maar de applicatie die binnen VM's draait en eigenlijk hetgeen is wat je wilt dat beschikbaar is kan je niet controleren vanuit de hypervisor. Daarom zou je dus je VM's ook nog eens moeten clusteren vanuit het applicatie-niveau
Maar om applicaties HA te maken moet je in eerste instantie het besturingssysteem HA maken, en daar gaat mijn project over...

Een hoog-beschikbaar virtualisatie platform levert zijn hoog-beschikbaarheid doordat je werkende servers via live-migration (of hoe het ook heet) naar een andere fysieke node overbrengt zodat de vorige fysieke node "down" kan voor bijvoorbeeld hardware onderhoud. Dat is dus een gepland en gecontroleerd proces.

Een hoog-beschikbaar virtualisatie platform (of HA) is eigenlijk niet hetgeen wat jij beschrijft, hetgeen wat jij beschrijft is bij VMWare bv LiveMotion, bij Hyper-V: Live Migration. HA is itt tot het intentioneel overzetten van VM's naar een andere host, het automatisch heropstarten van VM's op een andere fysieke host als de ene waar de VM's op draaiden plat gaat door bv een power failure...

Hoog-beschikbare virtualisatie levert je geen volledige oplossing voor ongeplande events.

In een bepaalde zin wel; voor het ongepland down gaan van een fysieke host en daarmede ook mijn VM's. De applicaties die binnen een VM draaien en die daardoor corrupt gaan, dat is een tweede punt ja...

[HyperBart]

Ik heb nu mijn cluster aangemaakt.
Mijn inventaris:
2x ML 110 G5
1x no-name servertje met 4 SCSI schijven, eentje gebruikt voor Windows XP Pro SP3 (up-to-date)

StarWind geïnstalleerd op de WinXP Pro, target aangemaakt op één van de fysieke schijven (één van de 3 overblijvende SCSI-schijven).

Drive gemapped in beide servers (zelfde iscsi-target), maar als ik nu iets aanmaak via de ene host laat de andere host dit bestand niet zien?

Ik kan ook geen disks toevoegen in mijn cluster, wat doe ik fout?

Edit: Je moet eerst de disks in alle nodes mappen via disk mgmt, als je ze dan gemapt hebt en je probeert de disks bij Virtual Manager toe te voegen, dan lukt dat, en vervolgens kan je ze in CSV toevoegen...

[ Voor 17% gewijzigd door HyperBart op 29-03-2010 16:52 ]