SQL 2000 Failover Clustering Logic?

  • quote:


    I've never been a fan of clustering...you still have a single point of failure-the SAN/disk arrays. You can achieve a similar level of redundancy without using a cluster and just using a standard RAID(1/5) setup. 95%+ of all failures from my experience happen in the disk array...not the CPU, not the power supplies, not the NIC, not the controller cards. It's interesting that failure usually happens in the most critical component-the disks. You can buy a new NIC, but you can't buy new data.


    True, but that is why I would never use clustering without a good SAN that offers redundancy throughout the entire I/O subsystem. We use EMC Clarion SAN's and have never had any data loss. Actually, we have never had a SAN related outage, but I have had several other hardware and software failures that were handled by the fail-over clustering. Before we started using EMC, we used Xiotech and we had a number of problems, including data loss, which is what convinced management that a rock solid SAN was worth the money.

    /*****************

    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek

    *****************/

  • quote:


    How difficult would it be to cluster two SQL Servers in an active/passive mode without a separate storage device? For example, have a RAID-5 array in each SQL server and have the active server log ship data to the passive server or use transactional replication to the passive server? Assuming that there is an effective, staggered backup plan in place, what would be the implications of such a configuration?


    It is impossible to cluster nodes without a seperate storage device using the Microsoft Clustering Service. There is one third-party solution that I know of that allows remote clustering with independent disks. The company is Incepto and the product is SQL Up. You might look into it. It isn't cheap, but it sounds like it fits what you are trying to do...

    http://www.incepto.com/products.htm

    /*****************

    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek

    *****************/

  • Jabba,

    I should have added that what you were describing in your last post isn't "clustering" but "log shipping". It isn't hard to setup assuming you will be using SQL 2000 Enterprise Edition. Again, the biggest drawback to log shipping is that failover is not automatic and any applications will have to be directed to the new active server.

    We have used both Log Shipping and clustering and I have found that clustering involves much less administrative overhead in the long run. But there is always a price to be paid...

    /*****************

    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek

    *****************/

  • I agree with the use of clustering with a redundant storage device. We use a DellSAN and have never had a problem, failover is in a matter of seconds. There is a third party option for failover without a shared device. It is by Legato, it's called Co-Standby Server AAdvanced. It's a costly option, but so is a reliable SAN. But if your apps can't take the downtime it's worth it. If you are using clustering, depending on number of processors, that isn't a 'budget' setup anyway.

    quote:


    Jabba,

    I should have added that what you were describing in your last post isn't "clustering" but "log shipping". It isn't hard to setup assuming you will be using SQL 2000 Enterprise Edition. Again, the biggest drawback to log shipping is that failover is not automatic and any applications will have to be directed to the new active server.

    We have used both Log Shipping and clustering and I have found that clustering involves much less administrative overhead in the long run. But there is always a price to be paid...


  • Regardless of how often, or how you do your backups, if you have never tried to restore the data to a different machine you are at serious risk.

    You should always do a periodic restore of your data to a separate server to test your recovery procedures. A disaster is no time to figure out that your tapes are bad.

Viewing 5 posts - 16 through 19 (of 19 total)

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