ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Application Clustering - Identifying Need vs. Want

    IT Discussion
    3
    5
    807
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • NetworkNerdN
      NetworkNerd
      last edited by

      We've just purchased some core licenses of SQL 2014 in conjunction with an ERP system upgrade. We'll have to use SQL 2012 as SQL 2014 is not yet officially supported by Epicor.

      But with the core license of SQL Standard, we automatically have license to create a two-node failover cluster (as long as one is truly passive). The SQL Server licensing guide from Microsoft states the following:

      SQL Server software can be configured so that if one server fails, its processing will be picked up, recovered
      and continued by another server. All editions of SQL Server 2012 provide basic high availability features
      including backup log shipping, database mirroring and two-node failover clustering. Advanced (AlwaysOn)
      high availability features in SQL Server 2012 Enterprise Edition include enhanced support for multiple, active
      (readable) secondary servers and support for multi-site failover clustering.
      Log shipping and database mirroring take place at the database level, whereas failover clustering takes place
      at the SQL Server instance level.

      We run 2 ESXi hosts with the latest version of 5.5 on local storage and use Veeam for backups. We've been told 1-2 hours is acceptable for the RTO with 24 hours being the RPO. Obviously IT pros are always looking to shorten that window when possible, but we do have to keep business requirements in mind (which I can currently meet by just restoring our existing SQL Server from a backup if it came to that, given the backups are solid and restorable).

      I realize we could use Veeam replication from one host to another to further shorten the RTO and RPO here. But, since I have license to create the SQL failover cluster, might it be wise to go ahead and do it to better the DR plan? That would then be something outside of relying on Veeam in the event that the SQL Server VM was hosed or its host was down completely. It would also be independent of SQL database backups. So I feel like there is a benefit to doing the cluster.

      This is one of those times where in my head it seems like it might be a good idea, but just because you can does not mean you should. I'd love to hear any input from others who have done application clustering (active / passive specifically) and some reasons for implementing.

      1 Reply Last reply Reply Quote 0
      • scottalanmillerS
        scottalanmiller
        last edited by

        Always take application clustering over platform clustering. Much more intelligence higher in the stack.

        1 Reply Last reply Reply Quote 0
        • alexntgA
          alexntg
          last edited by

          I just wanted to insert a supporting technical bit: In the event of failover if you're using Veeam replication, you aren't relying on Veeam at all. The replica is a VM on the other host. It's in a crash-ready state at the point the replica snapshot was taken.

          On to opinion - Is your current setup meeting RPO and RTO?

          NetworkNerdN 1 Reply Last reply Reply Quote 0
          • NetworkNerdN
            NetworkNerd @alexntg
            last edited by

            @alexntg said:

            On to opinion - Is your current setup meeting RPO and RTO?

            Yes, it is.

            alexntgA 1 Reply Last reply Reply Quote 0
            • alexntgA
              alexntg @NetworkNerd
              last edited by

              @NetworkNerd said:

              @alexntg said:

              On to opinion - Is your current setup meeting RPO and RTO?

              Yes, it is.

              In that case, anything else would be fluff. It would be important to weigh the added complexity with potential gains.

              1 Reply Last reply Reply Quote 0
              • 1 / 1
              • First post
                Last post