Mirror vs. Cluster - Which should we do?

  • We have about 130 databases for clients and are looking for high avail.

    In the next year we expect to double that.

    We can afford about $60,000 in equipment.

    The databases take up about 330 GB on HD now.

    What would you do Mirroring or Cluster as the next step?

    Right now we are log shipping and doing weekly backups to an off site location. I would not change that.

  • Since mirroring is done at the database level and clustering at the server level and you have a large number of databases; I'd go with clustering.

  • Thanks.

    Could you expand on your reasons.

  • Why not both?

    It sounds like you are already log shipping to a secondary site. You could use clustering at your primary site and mirror to a stand alone server at your secondary site. This gives you a layer of HA with clustering and DR with mirroring.

    Clustering is primarily for high availability and not disaster recovery unless you plan to geocluster/multisite cluster. You only have one set of data on disk.

    Mirroring can be used for HA and DR if you have another site to mirror to. This gives you 2 copies of the data so if site 1 disappears you can run on site 2.

  • Edogg (4/9/2010)


    Why not both?

    Cost!!

    Edogg (4/9/2010)


    Clustering is primarily for high availability and not disaster recovery unless you plan to geocluster/multisite cluster. You only have one set of data on disk.

    This is where we are confused - Why would anyone do Clustering at all?

  • Clustering does provide a level of protection - even if you consider it just a High availability solution. It does cost more to implement than a standalone server, but you do get the benefit of uptime should a server fail.

    Also, you can cluster servers that are in different buildings or are geographically disperse. Should one building lose power, you are still in business.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • This is where we are confused - Why would anyone do Clustering at all?

    Clustering provides quick failover, usually under one minute. With no changes for DNS (you connect to a virtual machine name, not a NetBIOS Server Name. Clustering also takes over all jobs/ logins, DTS packages, and is very low for administrative overhead.

    If a cluster fail's over, there is not much that needs to be done (except examine what happened). Many times I have found that a cluster has failed over, and no one even knew it (yes, that means that the monitoring solution needs tweaking).

    The most common solution these days is a cluster in your primary datacenter with log-shipping or mirroring to the backup data center.

    I would also echo the comment that with as many databases that you have, clustering will be a breaze versus setting up the other solutions, but clustering won't protect you for losing for first DC (geographically dispersed clustering will, but that's a whole different animal)

    /* ----------------------------- */
    Tochter aus Elysium, Wir betreten feuertrunken, Himmlische, dein Heiligtum!

  • My concern with implementing mirroring is based on the 130 current databases and that this could easily grow. There may be latency issues trying to establish that many connections between two servers.

  • Unless absolutely necessary I would not mirror that many databases. I would pick and choose which databases were to be mirrored.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Cluster is for quick failover for the server. You dont need to worry about logins, DBmail settings, and many other server level settings when you have cluster because it shares the same disk.

    Cluster does not provide muti site redundency of the databases. If mutisite redundency of database is required then you need to have mirroring or log shipping.

  • CirquedeSQLeil (4/9/2010)


    Unless absolutely necessary I would not mirror that many databases. I would pick and choose which databases were to be mirrored.

    Maybe 10-20 percent are not used hourly, the rest are high use and need a fail over.

  • The concern on cluster is we have the one device (the external Hard Drive Unit) as a fail point. It seems to be just a fancy piece of hardware that is just as likely to fail as any other server. So I my eyes a cluster is not safer than a single server. Where mirror I have a safe guard that if the Hard Drive fails in the main unit I can have the witness server move the traffic to the mirrored server.

    We are log shipping to a secondary location.

  • That's really dependent on your external drive source. If you just throw on and external drive bank via iSCSi with no redundancy or anything, then you're right.

    That's why most people use SAN's that have redundancy, large caches, considerable battery power, and well-thought out RAID arrays that provide redundancy and performance. That's not to say that all SAN's are great. A poorly configured SAN can be just as bad as any thing else.

    So if you are just planning to stick a cheap network drive array on the servers, maybe clustering is not the best option. I would spend my money on a better drive system before I start throwing more servers into the mix.


    My blog: SQL Soldier[/url]
    SQL Server Best Practices:
    SQL Server Best Practices
    Twitter: @SQLSoldier
    My book: Pro SQL Server 2008 Mirroring[/url]
    Microsoft Certified Master: SQL Server, Data Platform MVP
    Database Engineer at BlueMountain Capital Management[/url]

  • In addition to what Robert said, keep in mind that Mirroring or Clustering are really only a piece of the big picture for DR.

    Others have suggested a cluster that is mirrored. There is also geographic clustering. Then you add a SAN into the mix which has redundancy. Now throw in backups. There is also a design for backups to be considered for retention of those backups and storage location. Backups have also evolved to being able to be redundant as well - providing better DR for your company.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • i always like to say HADR - combining HA and DR together.

    Welcome to my website: DB Expert

Viewing 15 posts - 1 through 15 (of 51 total)

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