EMC SAN , Remote Mirrring , W2003 Clusters etc ....

  • Hi I I'm involved in deploying a new environment involving EMC DMX2000 SAN's which will be mirrored via SRDF to a remote site.

    A DR/BC environment will be available using "Remote Mirroring" as described in http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx. It will be a Windows 2003 2/3/4 node clustered. Conventional and MNS quorums will be used

    Availability is high with 100% no data loss of committed transactions in the event of primary site loss.

    EMC EDM/TSIM are being used for backup/recovery. Backend storage is to EMC Clarion.

    Is anyone doing anything similar , or have any experience in a any of the above ?

  • I've used this.

    TSIM is awesome,  I used to use TSIM to do that snapshot to back up the databases every night, and to also bring up a log shipping server during the day when transactions were high with the critical data.

    What kind of a distance are you going to be synching accross? And what kind of a synch are you going to run (semi/aynch), and will you be using a 2 pahse commit? I ask this because it will take a huge data pipe to get the data accross, and you might well experience latency, which means that should you be using a 2 phase commit it could take a while for transactions to be commited causing massive blocking and serious slowdowns on the database.

    Also you need to look at how you are going to bring up and attach the database on the far end, that can also be an issue as I have found in the past that out of 10 databases, 1 of them is almost certain to go suspect on you. If you are connecting to a remote database you also have to bear that in mind, as well as changes to indexes, and jobs if you are going to be bringing up the msdb.



    Shamless self promotion - read my blog http://sirsql.net

  • Hi thanks for the response. Distance is 100Km ish , we will have huge data pipes. The plan is to harwdware mirror synchronously which will have a latency penalty but should ensure consistency (in theory !) A write will not be complete until written at both sites and acknowledged.

    I don't like the sound of databases going suspect if attaching at the remote site. Does that happen in a controlled site-switch , or only if crashed ?. Did you run with SQL up at the standby end to maintain msdb and health check the standby system ?. Did you run this with MSCS clusters or stand-alone ?.

    Was your mirroring hardware or software ?

    Sorry for all the questions. We have been asking EMC and Microsoft but not having much luck. Any information you have on the "challanges" is much appreciated

  • What kind of data pipe are you going to have for this, dark fibre?

    Hardware mirror is good, in full synch mode (which is what it appears you are going to do) you will be doing a 2 phase commit, which means that it will only commit locally when it has committed at the far end. This could cause you major problems as you will be waiting for that response.

    We tried the controlled site-switch, in fact we broke the synch and then attempted to bring up the databases and it was a huge no-no. We did not keep SQL up simply because it would have caused it own problems. We actually used a dedicated job server, so we didn't worry ourselves with msdb, we just log shipped that to a standby job server.

    This was in a clustered environment, so we had named instances going. I think that the biggest thing that you have to concern yourself with is the SLA that you are looking at for bringing the database up and being fully ready to go, and also what amount of data loss is acceptable.

    Ultimately for us this did not work out, there were too many problems and we ultimately did a synch of the data and then started to do logshipping to the remote site.

    Regrading EMC, here is something that they love to do....promise you the world and get you to buy the product telling you all that it can do, and then once you are up on the system and dependant on it, all of a sudden you find that it can't actually do those things that you need it to do. If you can, get them in to set everything up and do a proof of concept to you so that you can see it working.



    Shamless self promotion - read my blog http://sirsql.net

  • Well you must have been reading our e-mails (or our minds ....

    EMC are planning to set up a test , but time is very short. We would love to discuss real world experiences with someone. Unfortunately PM doesn't work on the forum.

    The SLA's are a big concern as the requirement isn't just to use the standby site for DR , but also routine switching for maint etc.

    The other big problem is 100% no data loss for comitted transactions. Conventional log shipping isn't an option, but I can envisage a possible solution using a remotely mirrored tail of the log ....

  • Are you looking at using some kind of a 3dns system for handling the changeover from primary to backup sql node?

    Judging by what you are saying you are in a 24/7 e-commerce type environment, which of course means that everyone is up in the air and freaking about SLA's. I don't think that an SLA below 1 hour is actually pheasible, at least for what you are trying to do. Switching for maintenance is not going to give you anything, unless it's server maintenance, as doing anything to sql obviously requires you to be doing it on the data that's running.

    100% no data loss is a hard one, even with a dual phase commit there is the possibility of a lost transaction, have you looked at running in semi-synch mode, the data requirements are not as high and I believe (this was over a year ago so I could be mistaken) that you have the potential to only lose a single transaction.

    You absolutely have to test out your theories on whether this will work with a staging environment. We went through a period where we had major blocking and terrible performance for a week, everyone was rushing round checking indexes and trying to troubleshoot stored procedures, eventually we figured out that it was the synch mode on the emc slowing us down. We turned off synching and everything was fine. After that point any time we had a performance hit the question was asked "Are we running a synch on the EMC?". Make sure that you get hard requirements regarding the amount of data that is going to be moving on a constant basis, and remember that you will require a dedicated pipe for doing so. Then get with your network guys and ask them "Is this workable, and how much will it cost?". It's incredibly expensive just to even run semi-synch, if you want asynschronus that is going to be megabucks. Work out your own figures, don't listen to EMC and test, test, test before you commit yourselves.



    Shamless self promotion - read my blog http://sirsql.net

Viewing 6 posts - 1 through 5 (of 5 total)

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