locked
Database Cluster migration RRS feed

  • Question

  • I have an unusual situation where we have designed a strategic 2013 platform for a set of customers, which is a single shared farm with a physical DB cluster and several VMs for web front ends, services, distributed cache etc.

    The first customer to go on wants a platform created for them that potentially can operate stand-alone. This is on the basis that funding constraints may delay or even cancel the strategic platform so they want no dependencies upon it. A single VM has been proposed for their DB as a 'tactical' move and is appropriate for their small user base and what they are prepared to pay for.  They will also have a single WFE and a single app server. 

    The plan therefore would be to build the farm initially for the first client using SQL aliasing and a single SQL Server 2012 DB with a named instance.

    At some point we would look to migrate to the physical DB cluster once built and add more SharePoint servers to the farm and build up more web apps etc. for other clients. The SQL Server VM will be re-purposed to form part of the non-production environments.

    My question is whether I can use clustering as a migration strategy, either to create a new HA cluster and migrate the databases to it - or can I add the physical servers as nodes to a HA cluster that the VM is part of and then remove the VM as a node, leaving the physicals as a 2 node cluster. I guess I might need enterprise to have a temporary 3 node cluster or is there a way to do this using standard and Windows fail-over clustering?

    Potentially there is a different approach - any ideas gratefully received :)  

    for info, I have considered:

    cc512725(v=office.15)

    Move all databases in SharePoint 2013

    I was hoping that there is an alternative use of clustering which would be supported


    • Edited by Johnotech1 Monday, October 6, 2014 4:28 PM
    Monday, October 6, 2014 3:45 PM

Answers

  • The reason I started off with clustering with a single-node is because of the Enterprise Edition requirement for Availability Groups. With Standard Edition, you can have a 2-node cluster. I've done deployments of single-node clusters running on VMs for customers primarily for the purpose of reducing deployment costs. Later on, you can add a physical machine to this cluster, move the SQL Server instance to this physical machine and evict the VM so you can replace it with another physical machine. Should you decide to upgrade to Availability Groups later on, you just upgrade your instance from Standard Edition to Enterprise Edition without changing anything on your infrastructure. The failover cluster provides local high availability and you can use Availability Groups to provide disaster recovery capabilities to your content databases (SharePoint admin and config databases do not support asynchronous Availability Group replication just yet so you will need to create a separate farm for your DR.) If you decide to implement Availability Groups later on, you should create a DNS alias that points to your SQL Server failover cluster and use that to connect your SharePoint servers to the database. That way, when you add the Availability Group, you can just re-use that DNS alias as your Availability Group listener name. It also makes it easier when adding more servers in the farm as compared to creating SQL aliases.


    Edwin Sarmiento SQL Server MVP | Microsoft Certified Master
    Blog | Twitter | LinkedIn
    SQL Server High Availability and Disaster Recover Deep Dive Course


    • Marked as answer by Johnotech1 Tuesday, October 7, 2014 3:11 PM
    Tuesday, October 7, 2014 2:34 PM
  • The one thing I tell my customers when designing HA and DR solutions is to define the recovery objectives and service level agreements early on and make them the basis of any solution that they choose. I cover this in the free modules of my online course. In a SharePoint farm, you can be as general as the farm recovery objectives or as specific as the site collection recovery objectives. The sales site collection will definitely have a different recovery objective than the HR site collection so they will have to be treated differently. Both clustering and Availability Groups will not address an accidental deletion of documents in a site collection so you need to have the Recycle Bin feature turned on and have regular site collection backups.

    Edwin Sarmiento SQL Server MVP | Microsoft Certified Master
    Blog | Twitter | LinkedIn
    SQL Server High Availability and Disaster Recover Deep Dive Course


    • Marked as answer by star.wars Monday, November 10, 2014 6:48 AM
    Tuesday, October 7, 2014 3:20 PM

All replies

  • You can provision a single-node SQL Server failover clustered instance from the get go. You can't convert a standalone instance to a clustered instance so you would have to provision at least a standalone instance first and then a clustered instance to migrate the databases to it.  This plus provisioning a SQL alias to redirect SharePoint traffic once the database migration is completed. That's why starting off with a single-node SQL Server failover clustered instance would be the way to go to minimize impact and effort down the road. It's not highly available but it definitely functions the same as your standalone instance.

    Edwin Sarmiento SQL Server MVP | Microsoft Certified Master
    Blog | Twitter | LinkedIn
    SQL Server High Availability and Disaster Recover Deep Dive Course


    Monday, October 6, 2014 11:50 PM
  • Thanks Edwin,

    That's really useful advice about the single node failover cluster.

    With this single node cluster as the starting point, can I then add the two further physical boxes as additional nodes to this original failover cluster?  (I would then take out the original VM node)

    What I am asking is if there is a roadmap to just use clustering nodes rather than database migration to a new cluster to achieve what I need to do.

    Tuesday, October 7, 2014 8:32 AM
  • Why clustering? Always on Availability Groups is the current flavour of the day and it looks like MS is building that into SharePoint a lot more than clustering was or will be. I'm thoroughly sold after doing a HA build on it.

    Tuesday, October 7, 2014 8:56 AM
  • I am looking at clustering as an option using standard SQL Server licensing, (always on availability groups are an enterprise feature)

    but if there is a solution that relies on enterprise then its' an option I can explore - as per my post:

    'I guess I might need enterprise to have a temporary 3 node cluster or is there a way to do this using standard and Windows fail-over clustering?'

    Can I read into your above reply that I can achieve what I want to do using always on availability groups or are you just making the point that you'd be looking to use the newer enterprise features for redundancy given the choice?

     

    Tuesday, October 7, 2014 11:54 AM
  • The reason I started off with clustering with a single-node is because of the Enterprise Edition requirement for Availability Groups. With Standard Edition, you can have a 2-node cluster. I've done deployments of single-node clusters running on VMs for customers primarily for the purpose of reducing deployment costs. Later on, you can add a physical machine to this cluster, move the SQL Server instance to this physical machine and evict the VM so you can replace it with another physical machine. Should you decide to upgrade to Availability Groups later on, you just upgrade your instance from Standard Edition to Enterprise Edition without changing anything on your infrastructure. The failover cluster provides local high availability and you can use Availability Groups to provide disaster recovery capabilities to your content databases (SharePoint admin and config databases do not support asynchronous Availability Group replication just yet so you will need to create a separate farm for your DR.) If you decide to implement Availability Groups later on, you should create a DNS alias that points to your SQL Server failover cluster and use that to connect your SharePoint servers to the database. That way, when you add the Availability Group, you can just re-use that DNS alias as your Availability Group listener name. It also makes it easier when adding more servers in the farm as compared to creating SQL aliases.


    Edwin Sarmiento SQL Server MVP | Microsoft Certified Master
    Blog | Twitter | LinkedIn
    SQL Server High Availability and Disaster Recover Deep Dive Course


    • Marked as answer by Johnotech1 Tuesday, October 7, 2014 3:11 PM
    Tuesday, October 7, 2014 2:34 PM
  • Thanks for the clarification and detailed response - it's much appreciated.

    I'm now armed with the  information, options and road map to build the solution up :)

    Tuesday, October 7, 2014 3:14 PM
  • The one thing I tell my customers when designing HA and DR solutions is to define the recovery objectives and service level agreements early on and make them the basis of any solution that they choose. I cover this in the free modules of my online course. In a SharePoint farm, you can be as general as the farm recovery objectives or as specific as the site collection recovery objectives. The sales site collection will definitely have a different recovery objective than the HR site collection so they will have to be treated differently. Both clustering and Availability Groups will not address an accidental deletion of documents in a site collection so you need to have the Recycle Bin feature turned on and have regular site collection backups.

    Edwin Sarmiento SQL Server MVP | Microsoft Certified Master
    Blog | Twitter | LinkedIn
    SQL Server High Availability and Disaster Recover Deep Dive Course


    • Marked as answer by star.wars Monday, November 10, 2014 6:48 AM
    Tuesday, October 7, 2014 3:20 PM