Quantcast
Channel: Hyper-V forum
Viewing all articles
Browse latest Browse all 19461

HyperV 2012 JBOD architecture design and workloads

$
0
0

I'm currently studying architectural design considerations for deployment of HyperV 2012. We are currently utilizing Vsphere 5.0 essentials deployed on internal drive enclosures and had been planning to upgrade Vsphere licensing to utilize Vstorage for storage HA.

I do understand the possibility of leveraging many of the new scale out and HA capabilities provided in Win 2012 on top of the Vsphere platform, but have made a commitment to HyperV 2012 for the integration, standardization, technical skill set, and cost savings benefits that Windows 2012 now offers to small to mid sized customers.

I have never dealt with centralized storage, (SAN, NAS, JBOD, etc) in the past, and am designing a JBOD approach to my Win 2012 HyperV solution. I think I have my arms somewhat around this but would like some input on my approach, and possible pitfalls.

Workloads are very simple and low Volume: File services, AD, Exchange (will be 2013), Utility services (DNS, DHCP, Print, etc), SharePoint 2010/2013, Windows hosted web services, possible future virtualization of SQL server(Currently dedicated).

Hardware architecture is very basic also: 2 HP DL370 G6, currently utilizing 2 drive enclosures in each with Vsphere, (1 dedicated to VM's, 1 dedicated to data VMDK's) on each box.

My new approach for HyperV 2012 is to utilize 1 internal enclosure on each box to host VM's, and to deploy JBOD storage for data.

  • JBOD options are: 2 single interface JBOD's, 2 dual interface JBOD's, 1 Dual backplane Single interface per, 1 Dual Backplane dual interface JBOD

Proposed HyperV configuration is:

  • HyperV clustering of the 2 boxes
  • SoFS role at the host level with CSV shares to expose HA data to VM roles that can leverage this type of share, eg.(file servers)
  • Dice up some of each JBOD into mirroring to support roles such as Exchange DAG, and possible later SQL Server clustering. eg(1, (2 disk mirror) on each JBOD, Exchange installation maps to the mirror on it's direct attached JBOD for local copy of the database). Other work loads not utilizing host level CSV's would utilize other mirrors on their locally attached JBOD.

Points I'm seeking advice and opinions on:

  • Transparent failover is a nicety for me, short failover periods are acceptable. Very few of the VM's will likely be eligible
  • DataON is the only JBOD that I know of that is currently certified, it is a dual backplane, 2 interface per device, cost wise not too bad +-$5,500 for 24 bay. Believe it or not mgmt. will even cry about that. Per failover needs I believe 1 dual back plane single interface JBOD would be acceptable.....need comments on this, and the fact that I would be using a non-certified JBOD going with the later.
  • I know there are some issues with roles like Exchange DAG and SQL server clustering on top of HyperV clustering, are these issues alleviated simply by designating those roles as not HA on a HyperV cluster or should I simply not deploy a HyperV cluster, only the SoFS role at the host level?
  • I believe I have clarified SoFS at the host level is perfectly acceptable and understand that it could also be moved to the VM layer, just seems more versatile at the host layer, any comments or opinions?
  • Last, since I haven't dealt with JBOD's before I am a little perplexed by the Dual controller to separate JBOD's. I can understand this when redundancy is not provided through service like Storage Spaces and CSV's. There doesn't seem to be any need for this is my situation is there?

Thanks a lot everyone, not looking for absolute details I know this is a lot. Just clarification and opinions as at some of these layers I think I understand how to approach things, just worried about the pitfalls.

Chuck

   

Viewing all articles
Browse latest Browse all 19461

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>