[THIN] Re: Disaster recovery (continued)

Well with any replication config there are several options. Two basic
ones are always talked about and simplified:

 

One-way replication (Changes only replicated from a "master" to a "slave
or replica")  Two way replication (changes from both sides).

 

While these are basically true they are OVER simplified. When it comes
to Citrix there is really only one option since they only support one
(but more about that in a second). 

 

Anyway lets assume that we only have these two options. The best
alternative would be two way replication. This allows you to make
changes at either server (or DB) and have the changes replicated to the
other. The One way replication (while it sounds good) really is just
more of a hassle than it is worth since both types of replication take
the same amount of steps to configure. 

 

Now onto what is supported. The ideal is to make changes at either site.
So with that in mind we want "two way replication". MS SQL supports two
ways of doing this:

Merge replication - which has multi-master both databases writable and
making changes then sending them on to each other.

Transactional Replication with 2 phase commit -  which sends all changes
to the master (or publisher) then if the change does not conflict will
send it back to the replica as a valid change.

 

Transactional Repl is all the Citrix will support (even though merge
seems to work and NO ONE at Citrix could tell my what would break if I
used it). 

Anyway in this model one server is a Publisher (writable) and the others
are subscribers (not writable, kinda) 

The publisher is the main DB the one you created when you built the farm
AND the one that your Citrix server should point to when they are built.
The subscribers are then dispersed at your DR site or just other
Datacenters that host Citrix servers. Once the Citrix server is
installed it will then be "failed over" using DSMAINT to the local SQL
box.

 

When a change is made at this server that writes to the DS it is sent to
the local SQL box (the subscriber) this change is then sent to the
Publisher but not written to the DB. Once the change is at the
Publisher, it is verified as valid change that does not conflict with
any changes there. Then the change is incorporated to the DB and
replicated back to the Subscriber.  This basically creates the Writable
model for the subscriber its just that the change is sent to the
publisher, verified, then sent back to the subscriber. In this case the
publisher is still really the only writeable DB..

 

Of course Citrix always says One Way replication. But its not. One thing
you always here them say is that they should use the CMC against the
Publisher or master, never at the remote site. This is wrong, since they
say changes should never be made at that remote site that would update
the DS> My question was always what about the things that have to update
the DS, like drivers, like Hotfixes, etc... They get pushed out to the
server and have to update the DS... If it was really only one way and
the remote server was not writable then what happens to these changes?

 

Anyway that's long enough for the list...

Ron

 

 

 

Ron Oglesby

Senior Technical Architect

 

RapidApp

Office 312.372.7188

Mobile 815.325.7618

email roglesby@xxxxxxxxxxxx

 

-----Original Message-----
From: Andy Lalaguna [mailto:Andy.lalaguna@xxxxxxxxxxxx] 
Sent: Monday, September 08, 2003 2:31 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Disaster recovery (continued)

 

ron,

 

would you mind elaborating on this solution for those of us who wouldn't
admit to not speaking SQL very well.

 

Cheers, andyL

        -----Original Message-----
        From: Ron Oglesby [mailto:roglesby@xxxxxxxxxxxx]
        Sent: 08 September 2003 19:44
        To: thin@xxxxxxxxxxxxx
        Subject: [THIN] Re: Disaster recovery (continued)

        Use simple Transactional repl with realtime updates from the
subscriber. In this case the local Citrix boxes will point to SQL
servers at their site. In the case of the DR site (subscriber) Citrix
boxes will send Datastore changes to it. These changes are then sent to
the publisher which verifies they are ok, changes the DB then sends the
update back top the subscriber (all takes a second or two). 

         

        In the event of a low yield tactical nuke at the primary site
you can  make the subscriber a master/publisher and be ready to go to
add more servers or make changes. Until you make it a publisher you cant
make any changes.

         

        Don't even bother with a multi-master\Merge model. I tried it
and it works but Citrix refuses to support it. 

         

        Ron

         

        Ron Oglesby

        Senior Technical Architect

         

        RapidApp

        Office 312.372.7188

        Mobile 815.325.7618

        email roglesby@xxxxxxxxxxxx

         

        -----Original Message-----
        From: Stuart Hall [mailto:SHall@xxxxxxxxxxxxxx] 
        Sent: Monday, September 08, 2003 1:37 PM
        To: thin@xxxxxxxxxxxxx
        Subject: [THIN] Disaster recovery (continued)

         

        SQL replication of the datastore....didnt' think about
that.....would that be one way from primary to DR site? 

        If my primary goes down the DR site comes up independently and
writes to it's local datastore.  What timeframes would you recommend on
the replication (nightly, hourly)

        Is it really that simple?  I feel like I'm missing something. 
        ------------------------------ 

        Msg: #13 in digest 
        Subject: [THIN] Re: Disaster recovery 
        Date: Thu, 4 Sep 2003 17:15:29 -0500 
        From: "Ron Oglesby" <roglesby@xxxxxxxxxxxx> 

        Same Farm 
        Replicated Data Store with Citrix Servers in each location using
that 
        data store 

        CSG and NFuse at each site 

        Second site has a different URL  Unless you use some Smart DNS. 

        Use the same farm and what not... 

        OR you can technically create two different farms with the same
licenses 
        in each since you will only be using one at a time. 

         

        ------------------------------ 

         

        
        
_____________________________________________________________________
        This message has been checked for all known viruses by Reptons
internal virus protection and the MessageLabs Virus Scanning Service. 


_____________________________________________________________________
This message has been checked for all known viruses by Reptons internal
virus protection and the MessageLabs Virus Scanning Service.

Other related posts: