[THIN] Re: high availability
- From: "Ron Oglesby" <roglesby@xxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Tue, 11 May 2004 11:24:17 -0500
Ok when I talk of SQL in this context I am always referring to the Citrix
Data Store. Now My problem with the concept of pointing servers to the
master for maintenance is with the number of servers in a large environment,
having to change them from the read only replica to the master, then do
maintenance then change back, etc is just a pain.
Its easier to monitor and manage the replication than deal with changing
servers back and forth between Datastores. I have a client with 3
Datacenters and about 70-80 MF servers in each. To just do maintenance we
would be changing these back and forth all the time. Pain in the butt IMO.
Now as far as the orphaned or marooned DS replicas out there, you will have
this with ANY distributed model. I mean even if you just ship the logs you
now have DBs that are floating out there. With a Transactional model you
would turn one of the subscribers into the publisher, then break the
replication and have the other subscribers now replicate with the NEW
publisher. This of course assumes that the original publisher is not going
to come up any time soon (low yield tactical nuke to that datacenter or
something) But this depends on the type of loss, estimated recovery time
decision to move completely and recover in new data center etc etc
Ron Oglesby
Senior Technical Architect
Microsoft MVP - Windows Server
RapidApp, Chicago
Mobile 815 325-7618
Office 312 372-7188
e-mail roglesby@xxxxxxxxxxxx
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Lilley, Brian
Sent: Tuesday, May 11, 2004 11:03 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: high availability
also, if you had four marooned sites with read/write replica's of the Data
Store, how would you recover from this in terms of re-syncing the databases?
Thanks,
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On
Behalf Of Lilley, Brian
Sent: 11 May 2004 16:49
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: high availability
Big Ron,
When you say "SQL server", I assume you are referring to SQL based
relational
database servers in general and not specifically to MS SQL server.
Ok, now I may be being totally over-pessimistic about publisher/subscriber
replication here, but do you think it would be feasible to operate something
like the following: as part of a controlled maintenance window, point a
server
to the master copy of the datastore for the duration of updates to the data
store?
Are the benefits gained by having a simpler replication topology outweighed
by
the amount of effort to provide a maintenance schedule like above. I am
ultra
paranoid about a single global farm replicated between 8+ servers.
Would you trust the publisher/subscriber model for 8+ Data Store global
single
farm? Do you trust DSCHECK? Am I worrying too much?
thanks in advance,
Brian
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On
Behalf Of Ron Oglesby
Sent: 11 May 2004 13:46
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: high availability
Well. One thing that I can say is any location you have a Citrix server
using a SQL server the DB should be read/write/. Now what do I mean by that?
I mean that you should be using a publisher/subscriber model with
transactional replication/immediate updating. This will allow the changes
from servers talking to the subscriber to be pushed up to the Publisher
(master) written into the DS, then replicated to all servers.
The trick with this is that any servers online are going to have changes (of
some type, print drivers added, hotfixes added, etc). And these changes need
to update the DS. So I would not use a straight push for any SQL server with
hot online servers connecting to it. Now to use one as a COLD SQL server you
can do that. But lets assume a site loss. You have lost 50-75 servers in one
site along with the Datastore. Now you have a shipped Database to another
site. And you are going to start installing servers into that site to get
you up to capacity. All the shipping did was handle your published apps and
licenses for the most part, since the 75 servers are "gone" but remain as
ghosts in the DS and you still have to get a bunch of servers on line.
Get it?
Ron Oglesby
Senior Technical Architect
Microsoft MVP - Windows Server
RapidApp, Chicago
Mobile 815 325-7618
Office 312 372-7188
e-mail roglesby@xxxxxxxxxxxx
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Lilley, Brian
Sent: Tuesday, May 11, 2004 3:10 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: high availability
Big Ron,
Thanks again for your response.
I will be replicating a master read/write copy of the database to perhaps 5
major regional sites and maybe a couple more at a push.
Again, back to the DR hot-sites, should I make a data store present there
also?
I guess it's a balance between reducing the complexity of the data store
replication and having a truly 'marooned' DR site available almost
immediately.
Personally, from the feelings I got from this list, I would tend towards
keeping the data store replication to a minimum and allowing the DR scenario
the Citrix grace period to restore a data store onto an Oracle box which is
pretty straight forward.
When I first asked about data store replication some weeks ago, I mentioned
replication to ten servers globally for a single farm model (and most of the
old timers winced slightly). I am still looking to move forward with a
global
single farm with data store replication to a reduced number, prob 5 or so...
do you guys still hold the same view?
Also, can DSCHECK.EXE be trusted as a signature for health on the IMA data
store?
best regards,
Brian
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On
Behalf Of Ron Oglesby
Sent: 10 May 2004 20:07
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: high availability
Simple answer. No it does not need to be clustered. Complicated answer...
maybe.
I mean the real trick is how many (and what type) of changes will you need
to make if it is unavailable. In most cases your answer will be none. We can
operate without making changes to the DS for a couple of days. If that is
true then you don't need the cluster.
Replication or shipping of the DB/Logs is needed though for any type of DR.
Of course there are drawbacks to this too. I mean If you use transactional
replication then when the primary is gone you cant make changes anyway
(until you turn the subscriber into the publisher). So it all depends.
Hey, I can come out and work on this with ya. It sounds fun and right up my
alley.
Ron Oglesby
Senior Technical Architect
Microsoft MVP - Windows Server
RapidApp, Chicago
Mobile 815 325-7618
Office 312 372-7188
e-mail roglesby@xxxxxxxxxxxx
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Lilley, Brian
Sent: Monday, May 10, 2004 8:39 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] high availability
Chaps, I need to draw on your experiences again...
Does the primary IMA Data Store really need to be clustered, or is this more
complication than it is worth. KISS principle, etc.?
I appreciate that high availability is important, but isn't the integrity of
the database even more important. Without a Data Store, what's the worse
that
could happen during the 96 hours, you can't make changes??
If something was seriously wrong the master IMA Data Store cluster node A,
would we want the second cluster to take over? Is there not a further
chance
of corrupting data by having this nice-ity??
If the Data Store becomes unavailable, presumably an app server can still
boot
from the contents of the LHC?
thanks,
Brian
============================================================================
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
============================================================================
==
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
============================================================================
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
============================================================================
==
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
============================================================================
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
============================================================================
==
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
============================================================================
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
============================================================================
==
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
Other related posts:
