One large iSCSI target or multiple small ones?

[Travelcard]

This is a best practice question that I can't figure out.

We are using Starwind on two 2TB servers as the SAN for our virtualised Hyper-V network.

We will have two Host servers that have 32GB RAM and will host about 10 servers (File servers, print server, Exchange, forums, sharepoint etc.).

Now, should we create 1 large Starwind image (Host1.img = 2TB) file on each server and connect to it with iSCSI on each Host then put all our Hyper-V images on that one drive (LUN)?

OR

Should we create multiple Starwind image files to spread the drives amongst different iSCSI connections like this?:

ExchangeC.img (40GB)
ExchangeD.img (100GB)
ExchangeE.img (20GB)
FileserverC: (20GB)
FileserverD: (300GB)
etc., etc.
and then create a single Hyper-V VHD file inside all of those.

Which is best practice and what are the advantages, disadvantages of each?

Thanks for your time.

[aaron (staff)]

Multiple partially used images (hard disks) is only waste of space. Unless you'll use thin provisioning (and it's slow).

[Travelcard]

Cool, that's good to know

Thanks

[Travelcard]

The only reason we were thinking of using smaller images, would be in case the Starwind IMG file became corrupted somehow. If it did and we only had one large IMG file, we would lose all of our VHD files too.

[aaron (staff)]

Keep IMG files on RAID. Do backups.

The only reason we were thinking of using smaller images, would be in case the Starwind IMG file became corrupted somehow. If it did and we only had one large IMG file, we would lose all of our VHD files too.

[Thona]

The issue is no tthat simple of you ever want to move hyperv instances.

if you use StarWind as ONE LUN for ONE server, you can not easily move hyper-v instances.

I suggest:

* Use FILE servers for the vhd files of the operating systems. Do NOT use ISCSI, unless you run a file system that can deal with multiple hosts accessing them.
* Use separate ISCSI targets for the other discs within the hyper-v instances. The hyper-v clients can use their own iscsi initiators within hyper-v to talk to the SAN, so no config is necessary.

Plus put up a small ISCSI disck for quorum - voila, you are set to actually have a cluster with failover in hyper-v.

[Travelcard]

thanks for the reply. What is a "quorum"? I see it mentioned a lot but don't really understand what it is?

[anton (staff)]

It's for clustering. If you don't understand what's this - you don't need it

thanks for the reply. What is a "quorum"? I see it mentioned a lot but don't really understand what it is?

[Travelcard]

Good answer

[anton (staff)]

No way to know EVERYTHING

Good answer

[Travelcard]

The issue is no tthat simple of you ever want to move hyperv instances.

if you use StarWind as ONE LUN for ONE server, you can not easily move hyper-v instances.

I suggest:

* Use FILE servers for the vhd files of the operating systems. Do NOT use ISCSI, unless you run a file system that can deal with multiple hosts accessing them.
* Use separate ISCSI targets for the other discs within the hyper-v instances. The hyper-v clients can use their own iscsi initiators within hyper-v to talk to the SAN, so no config is necessary.

Plus put up a small ISCSI disck for quorum - voila, you are set to actually have a cluster with failover in hyper-v.

What we plan to do is have two Host servers. Each with a different large iSCSI drive.

HostA - iSCSI1
HostB - iSCSI2

If, for example HostA dies, we can browse for the target on HostB. Once that is connected we can start all the VMs on HostB

HostA - offline
HostB - iSCSI1 + iSCSI2

Does that sound OK?

[Thona]

It does not for me. Or: It would not be what I would like in MY case (and we run a similar setup).

You may want one day to hae a third machine.
You may want to move a single hyper-v instance to another server, to balance the load better.

Stuff like that.

I would (and do) set up a cluster solution here. And for that I need to be able to move individual system images. So, that setup would simply not work.

[anton (staff)]

Could you please put some more light on the question how cluster setup will help in this particular case? Thank you!

[Thona]

It is simple.

You ahve 2 HyperV servers
A
B
and a third one just in case (as A and B run at capacity)
C

Now, as this is a cluster...
...when A fails, C starts the stuff that was originalyl on C

SQL Server 2008 cluster services fully supports Clusters of Hyper-V instances.

But it is INSTANCES And if I want to move ONE virtual machine from A to C... I can not ahve all the system hard discs on one ISCSI target, if I use NTFS.

Note: There are third party file systems for that case, that support having multiple servers use them at the same time. so you could have ONE large ISCSI target, use that special file system and A, B and C would use the systemf iles frmo that target at the same time to start their virtual machines - but this costs another USD 300 per server.

So, that said I rather do not ahve ISCSI targets "per server" that host that servers virtual system drives.

[anton (staff)]

Understood! Thank you!