September 1, 2009 at 2:41 pm
Hi everyone, first of all thanks for any recommendations on this. I'll start off with our setup.
Currently we have a SQL 2005 Active/Passive Cluster setup with the data on a SAN. Up until recently we were happy with this config in that it allowed us to failover to the second server quickly. However, due to a bug in the firmware of our SAN, a disk failed and the bug caused the rest of the fibre disks to fail. We ended up having to restore from tape to recover our SQL data. Yeah fun.
So this leads us to looking for a way to have our data be redundant since our redundant SAN failed to be... redundant. I've looked at log shipping but the limitation that it can't handle file operations such as adding files is a problem. Also, mirroring doesn't leave the database in a recovered mode for quick migration, and I've found some databases don't support mirroring such as the SCCM database.
I've thought about breaking the cluster and use peer to peer replication but it seems like overkill for a backup server and backup data.
I would appreciate any comments or ideas on possible topology solutions.
Thanks again
Mike
September 1, 2009 at 4:31 pm
Do you add files a lot? Is that a major concern? Or is it a tradeoff you could make? If it doesn't happen a lot maybe you break the log shipipng and rebuild after adding the file. This limitation just doesn't seem like a deal buster.
I'm not a fan of mirroring.
Also how about SAN replication?
Is your SAN vendor taking care of you at all because thats a pretty big screwup? Vendors have gotten sued for that kind of stuff.
CEWII
September 2, 2009 at 3:30 am
I've looked at log shipping but the limitation that it can't handle file operations such as adding files is a problem.
What do you mean here?
I'm certain I have added files to a database, and the file has been created successfully at the log shipped secondary. The only time I have known it fail is if the drive/path doesn't exist on the secondary.
September 2, 2009 at 8:58 am
Thanks Elliot and Ian for the replies.
My worries come with doing log shipping on Sharepoint, the files aren't in a file share with a pointer in the database, they are in the database. http://technet.microsoft.com/en-us/library/dd890507.aspx only recommends log shipping content databases and sso databases. Now that you mention it, I would assume the data would be in the content databases, I'll have to chat with our sharepoint admins. Regardless however, without processing all databases, our recovery time would be that much slower for each database we couldn't do log shipping on.
I will have to look at san replication to see what possibilities we have there.
Thanks again guys, if there are any other ideas out there I would love to hear them.
Mike
September 2, 2009 at 9:05 am
With SAN, cluster and backups you should be ok.
SAN and cluster for immediate recovery, backup for delayed recovery.
I wouldn't set up a replicated db just to have data immediately available for recovery. There's a SAN for that. If it doesn't work, buy a new one.
Just my two cents, anyway.
-- Gianluca Sartori
September 3, 2009 at 12:08 am
What sort of clustering is it you use?
I use PolyServe Matrix these days (shared-everything) so we use a combination of mirroring, log shipping, and replication - for various reasons, in various places.
When I worked with a large MSCS cluster (shared-nothing) a few years ago, there were two physical SANs separated by about 500m or so, directly linked using 10G fibre with synchronous writes from one to the other. That works well, but is kinda expensive (even though both the cluster and SANs were active-active, it's still costly).
Paul
September 3, 2009 at 9:41 am
Thanks for the comments Gianluca and Paul, we are using MSCS, sorry I should have mentioned that in the initial post. Lol, the more I look into the databases and what they support the more frustrating it gets. Most Sharepoint dbs don't support log shipping, SCCM doesn't support mirroring, Sharepoint doesn't support peer to peer replication at all... We may have to do as you mentioned Paul and do a combination depending on which databases support what. SAN replication appears to be the only solution that isn't dependent on the database but I agree, it could be expensive.
Mike
September 10, 2009 at 10:00 am
Hi everyone, I just wanted to thank you again for all the replies. All the comments and experience was very helpful.
Mike
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply