[THIN] Re: Disaster recovery (continued)
- From: "Andy Lalaguna" <Andy.lalaguna@xxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 8 Sep 2003 21:33:04 +0100
Ron,
You are a gentleman, and I thank you for that description.
AndyL
-----Original Message-----
From: Ron Oglesby [mailto:roglesby@xxxxxxxxxxxx]
Sent: 08 September 2003 21:01
To: thin@xxxxxxxxxxxxx
Subject: [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.
_____________________________________________________________________
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:
