locked
High availability RRS feed

  • Question

  • hi

    I intend to set up a farm using the two tier model to support 500 users. Some of the solutions will be business critical and therefore I need to consider high availability. i could backup data and restore but this would take too long should a disater occur, what i was thinking about was some sort of mirroring for the sharepoint server and for the SQL server.
    I read somewhere that 'SharePoint Server 2010 relies on SQL Server’s fault tolerance mechanisms to provide high availability for SharePoint Server 2010 databases' . Could someone suggest the best strategy to enforce high availability for the farm please.

    Thanks

     

     

    Monday, June 20, 2011 2:08 PM

Answers

  • Hi,

     

    For high availability, I recommend load balancing the WFEs and the ASs for keeping the contents available. For the backend part, SQL Server failover clustering and database mirroring should be used to achieve best results.

     

    Have a look also at these links:

     

    Configure Mirroring: http://technet.microsoft.com/en-us/library/dd207314.aspx

    Configure Clustering: http://technet.microsoft.com/en-us/library/ms189134.aspx

    Plan for availability w/ SharePoint 2010: http://technet.microsoft.com/en-us/library/cc748824.aspx

    Mirroring best practices: http://technet.microsoft.com/en-us/library/cc917681.aspx

     

    Please bear in mind 2 things:

    1. Do not mirror usage and health collection data

    2. Mirroring cannot be used if you use Remote Blob and FileStream Provider

     

    I hope this provides a starting point.

    Best regards,

    Martin

     


    Martin W. Angler, MCTS

    Blog angler.wordpress.com
    Twitter: Follow me on twitter
    Monday, June 20, 2011 2:18 PM
  • Hi,

    I depends on your wallet and how critical your application is. There are many solutions for high availability. For WFE servers you can use a hardware load balancer to balance the load betwwen your servers, it's expensive but better than NLB which is free but require a lot of efforts to setup and configure. On the backend, SharePoint 2010 does support both mirroring and clustring.

    Mirroring is the cheapest one, since you don't need exactly same hardware configuration in your servers. Mirroring is run with two mode, synchron and asynchron. The synchron mode which is recommended for critical application you will need a witness server which will determined which server is principal and which one is mirror. Then in SharePoint when you create you databases you can set the mirror configuration. You need also to set up the mirroring in SQL, since mirroring is done on database-level and not database server-level.

    Database clustring on the other hand is more expensive but easier to configure. Many customers use the active/passive solution which gives you a rapid failover if one node in not functioning. You need only one SQL server license if you use active/passive, the same is true for mirroring.

    Both mirroring and clustring are supported in MS SQL 2008 R2 Standard Edition.

    There is a white paper written by Microsoft that tells you which databases are supported by mirroring and which are not supported. Tell me if you need more information.

    I would go for cluster, mirroring is a cheap solution but can give you site redundancy, since you don't need to have both nodes in same subnet as in clustring (you can achive that in a cluster by using iscsi).

       


    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Monday, June 20, 2011 2:33 PM

All replies

  • Hi,

     

    For high availability, I recommend load balancing the WFEs and the ASs for keeping the contents available. For the backend part, SQL Server failover clustering and database mirroring should be used to achieve best results.

     

    Have a look also at these links:

     

    Configure Mirroring: http://technet.microsoft.com/en-us/library/dd207314.aspx

    Configure Clustering: http://technet.microsoft.com/en-us/library/ms189134.aspx

    Plan for availability w/ SharePoint 2010: http://technet.microsoft.com/en-us/library/cc748824.aspx

    Mirroring best practices: http://technet.microsoft.com/en-us/library/cc917681.aspx

     

    Please bear in mind 2 things:

    1. Do not mirror usage and health collection data

    2. Mirroring cannot be used if you use Remote Blob and FileStream Provider

     

    I hope this provides a starting point.

    Best regards,

    Martin

     


    Martin W. Angler, MCTS

    Blog angler.wordpress.com
    Twitter: Follow me on twitter
    Monday, June 20, 2011 2:18 PM
  • Hi,

    I depends on your wallet and how critical your application is. There are many solutions for high availability. For WFE servers you can use a hardware load balancer to balance the load betwwen your servers, it's expensive but better than NLB which is free but require a lot of efforts to setup and configure. On the backend, SharePoint 2010 does support both mirroring and clustring.

    Mirroring is the cheapest one, since you don't need exactly same hardware configuration in your servers. Mirroring is run with two mode, synchron and asynchron. The synchron mode which is recommended for critical application you will need a witness server which will determined which server is principal and which one is mirror. Then in SharePoint when you create you databases you can set the mirror configuration. You need also to set up the mirroring in SQL, since mirroring is done on database-level and not database server-level.

    Database clustring on the other hand is more expensive but easier to configure. Many customers use the active/passive solution which gives you a rapid failover if one node in not functioning. You need only one SQL server license if you use active/passive, the same is true for mirroring.

    Both mirroring and clustring are supported in MS SQL 2008 R2 Standard Edition.

    There is a white paper written by Microsoft that tells you which databases are supported by mirroring and which are not supported. Tell me if you need more information.

    I would go for cluster, mirroring is a cheap solution but can give you site redundancy, since you don't need to have both nodes in same subnet as in clustring (you can achive that in a cluster by using iscsi).

       


    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Monday, June 20, 2011 2:33 PM
  • Hi

    Thanks for your help, So I see that SQl can have a mirror or cluster.

    How would an outage on the actual SP server thats running the application and web server be managed ?
    Would this be a copied server that remains idle and comes into action when a failure occurs ?
    If I install a webpart in the SP application server would I need to copy this webpart manually also to the redundant SP server?

    Thanks again

    Monday, June 20, 2011 2:59 PM
  • When i approached setting up High Availability I considered that it would also be a good Disaster Recovery strategy, they are not the exactly the same. I decided that what I was really looking for was disaster recovery. 

    If I was only considering High Availability, and not DR, then having the SQL Servers in the same site made the most sense to me for performance.

    However when preparing for disaster, I need to have a physically separated site that could be used for the disaster recovery equipment beause, if a true disaster were to occur, the main site would be destroyed.

    I had SQL Server 2008 Standard Licenses, so my options were limited to Full Database Mirroring or Log Shipping, or possibly a combination of the two.  If I had the Enterprise license I would have considered using Asynchronous Database Mirroring between my main site and the DR Site because using Full Database Mirroring across a VPN would have probably made my SharePoint Farm uselessly slow.

    In contrast to Asychronous Database Mirroring, in Full Database Mirroring, every transaction has to commit to the the SQL Server at the Main Site AND ALSO the SQL Server across my SLOW VPN link.

    If I wanted High Availability for users in the event that my SQL Server goes down,  I would have 'still' pursued a disaster recovery plan.

    For disaster recovery I used Log Shipping.  Log Shipping perfroms a backup then ships the backup across my VPN, and restores the backup to a 'warm standby' SQL Server which is part of a differernt Farm.  This is setup to happen every automatically 15 minutes. In the even of a disaster, and after a few documented steps,  I could have users accessing the new Sharepoint Farm within minutes, and without much, if any, loss.


    Robert Arroyo
    Monday, June 20, 2011 2:59 PM
  • Hi again,

    Once again it depends on your budget. At least you should have two WFE servers and one or more application servers. In SP 2010 Microsoft has eliminated single point of failure by removing SSP and adding service applications instead. When you install the first server, SharePoint will create your databases and you will have your farm. When you add the next server, all the configuration will be replicated to the second server. Installing farm solutions can be done in one server and the other server can consume and use those solutions or services. If you are tight on budget, start with one WFE server and then add more if needed, since you have only 500 users, performance won't be an issue. Use a lot of RAM and Gigabit NIC for your server.

    Remeber that a cluster or load balancing won't protect you against logical errors in your data, that's why you need a backup and restore strategy for your farm.


    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Monday, June 20, 2011 5:29 PM
  • Hi henrik

    Once again thans for the help. A couple of basic questions if you don't mind :

    if I compare a mirror to a cluster am I correct in thinking a cluster adds performance only (not backup) as an application request can be served by a number of servers in a cluster and a Mirror is not adding performance but a backup only ?

    Also, if i used a two tier model and backed up my SQL server only, should a disaster occur would the backed up SQL data suffice in a full farm restore (bearing in mind I have not backed up the Application/WFE server) ?

    In your answer above, would it be best if the two WFE ran on two physically separate servers ?

    I think I was trying to cover high availability and disaster recovery in my original post but did not communicate this well which Robert Arroyo (above psst ) brought to my attention.

    (Plan A) would be to start at primary location with two tier system (two separate servers, one for WFE/App and the other for db) and a similar setup in 2nd location. Using mirror or log ship the data to 2nd location (100 miles away, 10Meg line). Both locations would require access to SP.
    This way I have high availability and disaster recovery solved.

    (Plan B) would have high availability at primary location consisting of 2 wfe's and two SQL server. For disaster recovery aspect, an automatic backup would be stored at the 2nd location. Should a disaster occur there would be a delay in restore but because of high availability factored in the chance would be reduced.

    If someone could answer the above questions and provide feedback on plan A/B I would appreciate. Thanks

     

     

     




    Tuesday, June 21, 2011 8:43 AM
  • if I compare a mirror to a cluster am I correct in thinking a cluster adds performance only (not backup) as an application request can be served by a number of servers in a cluster and a Mirror is not adding performance but a backup only ?

    Both cluster and mirrorig give you high availability not performance. The performance maybe true if you use active/active cluster. If you want site redundancy as I mentioned above, mirroring is a better and cheaper solution. It covers your disaster recovery scenario too. You can achieve it with clustring too, then you need to use iscsi.

    Also, if i used a two tier model and backed up my SQL server only, should a disaster occur would the backed up SQL data suffice in a full farm restore (bearing in mind I have not backed up the Application/WFE server) ?

    The best practice is to backup your entire farm, and it means your WFE/App server(s) and your databases. You need to backup the system state, HIV 14 and IIS metabase.
    You don't need to have them on physical servers, you can use virtualization if you have a data center solution as Hyper-V or VMware. 

    Plan A is good to start with, 10 Mbit/s /s line is may not be enough, you should have a Gigabit NIC and a higher transfer rate. It depends of course on how heavy collaboration site you have and how much read and write you have. Remember than in synchron mirroring you need to commit the transaction to both nodes and that can be time consuming. Microsoft recommend less than 1 ms delay for the trafic from WFE/APP to databas server. 

    Plan B is for the future and gives you high availability and disaster recovery options.  


    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Tuesday, June 21, 2011 9:16 AM
  • Hi

    i always thought the '1 ms delay ' was specific the internal working of the farm. Would a mirror in another location be seen as the same farm as the original? how about I used async mirror mode or log ship instead?


    Tuesday, June 21, 2011 9:43 AM
  • async and log shipping will work fine, but you need to commit transaction logs manually.
    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Tuesday, June 21, 2011 9:48 AM
  • Think I'll go for sync mode and see how things go, good to have options though :)

    The best practice is to backup your entire farm, and it means your WFE/App server(s) and your databases. You need to backup the system state, HIV 14 and IIS metabase.

    If I mirror the sql server to another backup farm (remote location) which of the above steps would I need to carry out? How often? and is there an automatic way to do this ?

    Sorry about all the questions.

    Tuesday, June 21, 2011 9:56 AM
  • It will be my last answer, then you can buy consulting :)

    The mirroring is done at the database-level, so it gives you redundancy for you databases, but not your WFE/APP. The IIS metabase, HIV 14 and system state must be carried out seperately.


    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Tuesday, June 21, 2011 10:10 AM
  • Thank you for your assistance and time.
    Tuesday, June 21, 2011 10:45 AM
  • If you are satesified with the answer please mark it as Answer, then others know that you have got what you wanted.
    Regards

    Henrik A. Halmstrand http://www.sharepointrevealed.com
    Tuesday, June 21, 2011 5:35 PM