iSCSI initiator for 2012 Hyper-V

besamsam · Thu Dec 06, 2012 5:38 pm

Due to I use 2 QNAP NAS as 2 iSCSI target, so I don't need the SW iSCSI SAN software.
I don't want to setup 2 Windows server act as iSCSI SAN storage, QNAP NAS does all the thing just power on that work.

I want to install the SW initiator on Server 2012 Hyper-V as a hypervisor with HA . So to make a mirror iSCSI HA VM storage (storage HA) for protect when one of the NAS offline, then another NAS can continuous provide service for hypervisor.

Fri Dec 07, 2012 11:07 am

This proposed design brings a number of issues rendering it useless finally. Let's go step-by-step:

Technical.

1) As you're routing both iSCSI SAN boxes thru a single Windows Server 2012 you do effectively have it (Windows box) as a single point of failure.
To have a redundancy you don't have to have ALL of the componentsbeing protected. You leave major (and probably weakest one) as unprotected.

2) Microsoft is checking for underlying storage type during cluster shared volume creation. If storage is create with an let's say "unknown" component
(such as StarPort to MS operating environment is) you're not going to be allowed to create CSV on it. So even if you'd mentally pass 1) you'll be stuck at 2).

Support.

1) This configuration is unsupported by both Microsoft (who don't want to support bunch of unknown kernel components) and StarWind. We both have
"blessed" way to go (for MS it's using MS initiator or hardware drivers and for StarWind it's using our SAN solution) and want our paying customers to stick with it.

So proper way for you to go would be installing Native SAN for Hyper-V on a both Windows machines and clustering both QNAP boxes with it. It's absolutely
supported by MS and StarWind config, you'll have true HA and you'll have performance benefits as StarWind will cache I/O on a Windows boxes (with QNAP
all of the reads and writes need to trevel thru the wire slowing down everything dramatically).

eliripoll · Sat Dec 15, 2012 7:41 pm

Hi, I re read this and i think i read his question differently, i don't believe he wants to route both iscsi thru one 2012 server as you mentioned in your responce i think what he wanted to do was use the SW initiator (raid 1 maybe) to have redundant storage of both NAS's and install the Starport Initiator on another 2012 server also using (raid 1 initiator). then somehow use clustering to allow both servers to act as HA for each other.

I know the normal response is to use SW HA or native SAN, but his Question got me thinking. If an organization bought 2 storage nas/sans. and for sake of this question (they dont/cant replicate with each other). But you still want to have Storage HA as well as Server HA, would the only way to do this is use SW HA and create an ISCSI target from the server that sits on top of an ISCSI target to the SAN/nas? Just curious. I modified his picture below a little bit to illustrate.

my questions are could you create a cluster where you first create a regular standard quorum disk that works like normal but somehow use starport's raid 1 feature (which is awesome) on both servers pointing to the same data iscsi target as a 2nd shared resource disk? ill give it a shot and test anyway see what flips out.
or if not
what about the possibility of creating a new version of the Starport initiator that supports 2012 Storage spaces

, since the starport initiator is a driver it can probably be made to make windows think its a local disk (sas capable?) see Storage Spaces

basically rather than a raid controller that sits between the OS and the disk the unit passes all disk to the server 2012, and i guess 2012 see some header info and know is part of a storage space. what if the starport driver faked out 2012 so it though "hey its an attached disk and i see its a storage space disk"

Im just throwing out some ideas , since i can see some cases where this setup would be needed. like if the servers you had had were 1u w/no space for attached storage

also this link also give me a feeling that maybe the idea is not so far fetched.
http://blogs.technet.com/b/askcore/arch ... chine.aspx

thanks

Sun Dec 16, 2012 10:40 pm

There are many ways to skin the cat (c) ... So yes, it's possible in theory to re-write StarPort to be Clustered Storage Spaces compatible (not an easy task
as completely new model should be selected, basically we'll just dump whole thing we have so far and will have to create new one from the scratch), yes,
we can add data synchronization, cache coherence and distributed lock managers (and these components are missing from design from the very beginning,
writing a mirror is quite an easy task compared to reservation conflict resolver) to... To what? Provide people with a Windows-only solution to cluster Hyper-V?
And still with a need to have an iSCSI target on top of it to have a guest failover clustering (iSCSI or FC are still required)? For now we have a solid core,
working on ALL hypervisors and on Windows we don't require extra component as we're iSCSI target ourselves (think about shorter I/O path and active-active
design we provide). That's why solution we offer (iSCSI SAN & NAS on top of it) is superior to a simple storage driver based one. Sad but true (c) ...

eliripoll · Mon Dec 17, 2012 9:57 pm

understood thanks for taking the time to read my long post,

so if someone did have a 1u server and a SAN like the gentlemen mentioned. Would it be ok to first create a iscsi connection to the san on one nic port. then on a different Nic port create another iscsi target with SWS? that would seem like a simple solution, do you know if there will there be any performance drawbacks (minor or major?) going to an iscsi target Of An iscsi target using SWS.

regarding the storage spaces with star port, it was just a thought since it seemed that windows would still handle resource sharing if all nodes saw same 'local disk' as with the jbod, didnt want you to dump what you have done so far, its great stuff.

Mon Dec 17, 2012 10:05 pm

Yes, he'll install StarWind software on both Hyper-V nodes and it will take two SAN/NAS boxes not talking to each other and mirror them.

There's not going to be any performance drawbacks just the opposite: StarWind will provide I/O acceleration and caching (RAM & flash) so less and less I/Os will
actually have to leave the hypervisor machine and touch the wire (with originally proposed design ALL I/Os will be routed over network and this is SLOW). So
StarWind will do ACCELERATION BOOST for NAS/SAN.

eliripoll wrote:understood thanks for taking the time to read my long post still,

so if someone did have a 1u server and a SAN like the gentlemen mentioned. Would it be ok to first create a iscsi connection to the san on one nic port. then on a different Nic port create another iscsi target with SWS? that would seem like a simple solution, do you know if there will there be any performance drawbacks (minor or major?) going to an iscsi target Of An iscsi target using SWS.

regarding the storage spaces with star port, it was just a though since it seemed that windows would still handle resource sharing if all nodes saw same 'local disk' as with the jbod, didnt want you to dump what you have done so far, its great stuff.