Se connecter
 
AccueilLibrairieFormationTéléchargementsSupport techniqueCommunautésForums
Pour les professionnels de l’informatique >
> 
> 
Hyper-V Cluster with a SAS, Yes for Physica, No for Guests, how about CSV?

Answered Hyper-V Cluster with a SAS, Yes for Physica, No for Guests, how about CSV?

  • dimanche 29 avril 2012 04:27
     
     
    Connectez-vous pour voter
    0
    Windows 2008 R2 Failover clustering supports DAS as long as it is SAS.  So when I spec'ed out my hardware I requested a SAS Array that I could configure as Raid 10 Storage for my Physical Computers.
     
    So I am tackling our HP P2000 SAS and the plan was to Install Failover Clustering on 3 Proliant servers connected to the SAS.  Once this is done my plan is to configure the storage as Clustered Shared Volume (CSV) which will allow me to use live migration to move running VM's between physical computers.  I think this will still work with my SAS.
     
    This is probably fine for my 2 x WFE which will be in a Windows NLB Cluster and not in a Failover cluster.
     
    My plan was to create a SQL Server 2008 R2 Failover cluster within my SQL Server 2008 R2 VM's.  I just learned that I cannot do Failovering clustering of my VM's without iSCSI.
     
    I am thinking of ways to proceed.
     
    A.  One options could be:
    1) Install SQL Server 2008 R2 directly on two physical servers that are also running Hyper-V.  May need to provision some storage that is not CSV for SQL Server.
    2) Run my WFE's in VM's configure NLB as planned.
     
     
    B. Another:
    1) I could configure one of my three servers as an iSCSI target.  I could then configure an iSCSI SAN.  I would need to dedicate a NIC on each server for my iSCSI Storage area Network.
     
     
    C. Another:
    1) Skip Failover cluster for SQL and install a SQL VM on each physical server and use SQL mirroring to protect my SharePoint databases.
     
     
    A. Option A seems appealing to me since I would be able to protect SQL with a Failover cluster which I have configured before (in labs).  There may be some added benefit of running SQL Server outside of a VM.  It somehow seems wrong  to run SQL on the same box as Hyper-V without running it in a VM.
     
    B. Not sure about license.  If we don't have a license for an iSCSI target, cost is a consideration.  The iSCSI provider (target) would be a single point of failure unless it is clusterable. (seems unlikely)
     
    C. I am not familiar with SQL Mirroring, not sure if you have to manually switch to a mirrrored DB.  Also I thought there were some DB's can't be mirrored in SharePoint (maybe just not in UI but through powershell?)
     
    I would love to hear some educated opinions on this situation.

    Thanks for taking the time to read and respond.

    Greg

    Gregory Frick

     

Toutes les réponses

  • dimanche 29 avril 2012 09:18
    Modérateur
     
     
    Connectez-vous pour voter
    1
    Also, You can install iSCSI Target 3.3 on virtual machine with pass-through disks from your SAS storage and use guest SQL cluster.
     
  • dimanche 29 avril 2012 09:48
    Modérateur
     
     
    Connectez-vous pour voter
    1
    Hi,

    If the DAS has fiber channel, you can use it for Hyper-V Failover Cluster.

    By the way, install other applications on Hyper-V is not recommended, especially in production environment. If you are in a test environment, you can put iSCSI Target in one virtual machine and then install SQL Server in other virtual machines.

    In addition, for SQL mirroring issue, it is recommended that you perform the further research in SQL corresponding community so that you can get the most qualified pool of response. Thanks for your understanding.

     
  • dimanche 29 avril 2012 12:31
     
     
    Connectez-vous pour voter
    2
    Also, You can install iSCSI Target 3.3 on virtual machine with pass-through disks from your SAS storage and use guest SQL cluster.

    Yes, it's even possible to have poor-mans HA with MS iSCSI in such a case. Here's a guy did it with diagrams:

    http://techontip.wordpress.com/2011/05/03/microsoft-iscsi-target-cluster-building-walkthrough/

    Very long I/O route, all benefits of a low-latency SAS nuked, performance absolutely sucks :(

    -nismo


     
  • dimanche 29 avril 2012 12:33
     
     
    Connectez-vous pour voter
    1
    Hi,

    If the DAS has fiber channel, you can use it for Hyper-V Failover Cluster.

    By the way, install other applications on Hyper-V is not recommended, especially in production environment. If you are in a test environment, you can put iSCSI Target in one virtual machine and then install SQL Server in other virtual machines.

    In addition, for SQL mirroring issue, it is recommended that you perform the further research in SQL corresponding community so that you can get the most qualified pool of response. Thanks for your understanding.

    How can you configure guest VM cluster with FC? I had an impression FC is supported for such a scenario in Hyper-V 3.0 / Windows 8 only...

    -nismo

     
  • dimanche 29 avril 2012 12:42
     
     
    Connectez-vous pour voter
    1
    Windows 2008 R2 Failover clustering supports DAS as long as it is SAS.  So when I spec'ed out my hardware I requested a SAS Array that I could configure as Raid 10 Storage for my Physical Computers.
     
    So I am tackling our HP P2000 SAS and the plan was to Install Failover Clustering on 3 Proliant servers connected to the SAS.  Once this is done my plan is to configure the storage as Clustered Shared Volume (CSV) which will allow me to use live migration to move running VM's between physical computers.  I think this will still work with my SAS.
     
    This is probably fine for my 2 x WFE which will be in a Windows NLB Cluster and not in a Failover cluster.
     
    My plan was to create a SQL Server 2008 R2 Failover cluster within my SQL Server 2008 R2 VM's.  I just learned that I cannot do Failovering clustering of my VM's without iSCSI.
     
    I am thinking of ways to proceed.
     
    A.  One options could be:
    1) Install SQL Server 2008 R2 directly on two physical servers that are also running Hyper-V.  May need to provision some storage that is not CSV for SQL Server.
    2) Run my WFE's in VM's configure NLB as planned.
     
     
    B. Another:
    1) I could configure one of my three servers as an iSCSI target.  I could then configure an iSCSI SAN.  I would need to dedicate a NIC on each server for my iSCSI Storage area Network.
     
     
    C. Another:
    1) Skip Failover cluster for SQL and install a SQL VM on each physical server and use SQL mirroring to protect my SharePoint databases.
     
     
    A. Option A seems appealing to me since I would be able to protect SQL with a Failover cluster which I have configured before (in labs).  There may be some added benefit of running SQL Server outside of a VM.  It somehow seems wrong  to run SQL on the same box as Hyper-V without running it in a VM.
     
    B. Not sure about license.  If we don't have a license for an iSCSI target, cost is a consideration.  The iSCSI provider (target) would be a single point of failure unless it is clusterable. (seems unlikely)
     
    C. I am not familiar with SQL Mirroring, not sure if you have to manually switch to a mirrrored DB.  Also I thought there were some DB's can't be mirrored in SharePoint (maybe just not in UI but through powershell?)
     
    I would love to hear some educated opinions on this situation.

    Thanks for taking the time to read and respond.

    Greg

    Gregory Frick

    1) You can configure HA iSCSI without wasting a dedicated machine and a server license. Both StarWind and DataCore have a scenarious a pair of a DAS-equipped Hyper-V boxes can create a cluster to feed iSCSI SAN to themselves. Like this one:

    http://www.starwindsoftware.com/native-san-for-hyper-v-benefits

    http://www.starwindsoftware.com/images/pages/nativesan/img33.jpg (diagram on how it works compared to a "classic" iSCSI SAN on a dedicated nodes)

    ftp://support.datacore.com/psp/TBs/TBulletin18_NAS_SAN.pdf

    (check page 6, they show it for a SMB/CIFS file share but the same is true for any scenario)

    2) Yes, database mirroring can be the way to go. However with SAN running on the same Hyper-V nodes you have THE SAME I/O route - ALL reads go local (and they are effectively cached of course) and all writes get "acknowledged" by writing to cache of the pair node (network layer utilized). With "classic" iSCSI SAN all I/O always hit the wire - read or write does not matter. So if your database is oriented mostly on reads then SQL database mirroring OR running SAN software locally would be ages faster.

    -nismo


     
  • mercredi 2 mai 2012 08:47
    Modérateur
     
     
    Connectez-vous pour voter
    0
    Hi,

    Have you tried the suggestion? I want to see if the information provided was helpful. Your feedback is very useful for the further research. Please feel free to let me know if you have addition questions.
     
  • mercredi 2 mai 2012 17:33
     
     Traitée
    Connectez-vous pour voter
    0

    Hi All,

    Thanks for all your responses and ideas.  The approach I am taking right now is to:

    1. Build the Cluster on my 3 physical machines. (*done)

    2. Install the Hyper-V role on the 3 physical machines (done)

    3. Create four networks in Hyper-V  (done)
    •1 bound to Nic 1 shared with management computer
    •1 bound to Nic 2 not shared with management comptuer
    •1 bound to Nic 3, private address space, no GW, no DNS for Live Migration
    •1 bound to Nic 4, private address space, no GW, no DNS, heartbeat, SAS Web Management

    4. Configure some of my SAS storage as CSV. (*done)

    I set this up and I have moved my storage from node to node in the Failover Cluster Admin console.  I am not 100% sure on my network configurationa and how to "tell" Failover Cluster what network is for what purpose.

    Next steps

    Add test VM and figure out how to migrate it from machine to machine.

    Add test SharePoint farm and see out that behaves.

    I don't think this configuration will give me automatic failover of SQL within the VM. However, if one of the physical machines fails all the VM's on that machines should fail to one of the other nodes in the cluster.  It should also allow me to move SQL from one physical box to another using live migration which will help with maintenence tasks.

    I may explore using iSCSI in the future, but I need to consider it in the context of what I get without Failover cluster within the VM's vs. what I would get with Failover cluster of the Physical machines with Live Migration.

    Greg

    Gregory Frick

     
  • mercredi 9 mai 2012 09:04
     
     
    Connectez-vous pour voter
    0

    Hi All,

    Thanks for all your responses and ideas.  The approach I am taking right now is to:

    ...

    I may explore using iSCSI in the future, but I need to consider it in the context of what I get without Failover cluster within the VM's vs. what I would get with Failover cluster of the Physical machines with Live Migration.

    Greg

    Gregory Frick

    Greg, Live Migration is not a replacement for failover clustering, they are pure complimentary solutions. You really need to answer a question: do you want to have protection from downtime or not. If you're fine with VM downtime and need LM only to put physical nodes down for a service - that's fine and makes everything much simplier. Here's a good article about the subject in general (not technical one):

    http://www.smbitjournal.com/tag/high-availability/

    Hope this helped :)

    -nismo

     
  • mercredi 9 mai 2012 16:13
     
     
    Connectez-vous pour voter
    0

    Hi Nismo,

    I would probably phrase "complimentary solutions" differently.  Live Migration is a feature of Failover Clustering.  In marketing material Live Migration is presented as a feature of Hyper-V, it is more accurate to describe Live Migration as a feature of Failover clustering.

    So now that my physical computers are in a Failover Cluster, the VM's on those nodes are clustered services.  If a physical node fails the VM's running on that node will failover to another node. The services and applications running on a failed-over VM won't know what happened.  The services and applications won't have had the chance to finish what they were doing (write cache to disk, commit database updates,etc) so when the VM's start up on the surving physical node they may have lost some data. 

    I will post a question in a SQL Server forum to get some opinions on how robust SQL Server is this situation. I think it is pretty robust.  I will also look into how robust SharePoint is in this situation.  My SharePoint VM's are in a NLB Cluster, so if one of my SharePoint VM's is non-responsive the users will experience minimal service interuption.

    Thanks for the link to the article.  I will check it out and thanks for your reply,

    Greg

    Gregory Frick