Post reply

2 server working as hot / standby

  • July 16, 2006 at 3:41 am

    #92132

    Hi all,

    Planning to have 2 same server having similar data (live).

    The idea is to have 2nd server providing full service to users when one is down, 100% availability.

    please advise me how to start including hw requirement.

    thanks a lot, regards Vikram

  • July 18, 2006 at 9:47 am

    #649845

    ISBN 0-7356-1920-4

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • July 18, 2006 at 12:27 pm

    #649903

    By the way there is not such thing as 100% availability


    * Noel

  • July 18, 2006 at 2:59 pm

    #649962

    I would beg to differ < grin > seen July Technet mag ? Load balanced sql server 2005 clusters using peer to peer replication .. is that cool or what?

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • July 18, 2006 at 3:39 pm

    #649975

    Yeah, yeah, yeah...  all looks nice on presentations and usually the achievability of that is unrealistic. What would happen on the next 'upgrade', service pack, driver update, hardware refresh, backup etc... Can you guarrantie NOTHING WILL fail? ... I doubt it!

     


    * Noel

  • July 18, 2006 at 11:21 pm

    #650009

    Hi all,

    I agree with noeld about no 100% gurantee, specially during upgrade etc... but upgrade will be planned outage, I was trying to achieve here is maximum availability due to say HW fault, service not working or a power failure or so.

    If anyone can give me a idea i will be grateful, please try to share your thoughts on possibility.

    I will try to look into a suggestion by Colin i.e. ISBN 0-7356-1920-4.

    Thanks again for replying.

    regards Vikram

  • July 19, 2006 at 8:41 am

    #650125

    As an example of how Peer-to-Peer does NOT guarranties 100% availability, this is what BOL has to say:

     

    Maintenance Considerations

    • The following actions require the system to be quiesced (stopping activity on published tables at all nodes and ensuring that each node has received all changes from all other nodes):

      • Adding a node to an existing topology
      • Adding an article to an existing publication
      • Making schema changes
      • Restoring a node from a backup

    It has been my experience that schema changes ARE common

     

    Vikram,  You do need to read the High Availability book but just keep in mind that there is no silver bullet option. You will need compromises and if you mix technologies you could cetainly get closer but the admistrative overhead will be felt.

    My advice: go with the simplest that 'approaches enough' to your requirements do not overengineer the solution.

    Cheers,

     


    * Noel

  • July 19, 2006 at 9:08 am

    #650138

    Sorry guys read the article, it's how microsoft run their technet,msdn and other web-sql server sites. It uses 4 sql servers maintaining seperate databases via peer to peer.

    When I first saw peer to peer it seemed there could be possibilities, failover is always going to be failover and I've been asking ms to load balance for ages - ok they say it can be done - I believe them < grin > Check out July Technet Magazine, then see what you think.

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • July 21, 2006 at 11:24 pm

    #650907

    Thanks to all of you for support.

    noeld, I will try and maintain with your suggestion but at this point I don't know how will I proceed, I was just gathering some info (more than one possibilities) to submit and discuss with my boss.

    I will post here later once I manage to get it done, I have a feeling my boss may stick to present one server solution based on all the info from this forum.

    thanks again and have a good day.

    regards Vikram

  • July 22, 2006 at 8:04 am

    #650921

    As Noel says it's all a matter of cost vs complexity. When most people state 100% availability what they actually mean is always available during working hours - or something.

    I use a combination of log shipping, clusters and replication with remote DR sites to provide availability, however none of this currently is near five nines.  The big drawback to availablility has always really been the disk subsystem ( shared clusters ) and a cluster is merely failover anyway, with a large number of databases bringing the node on-line can sometimes take some time. 

    The other concern is switching/re-connecting your clients , even if your hardware is good in a disaster if all the clients have issues then you're still not getting it right. I had an app that locked all the clients out when the cluster failed over, no joke sorting out 700 odd clients who've all become locked out! Replication is good but databases need to designed with replication in mind - mirroring is good but has some limitations for clients ( like my cluster problems ) and there's always the issue of latency and where do you place the other server and the witness. 

    Log shipping is still one of the easiest ways to protect your data and is still my favourite, although it won't give anywhere near 100%.

     

     

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply