Re: Why Cluster in a test Environment?
- From: "Joe Yong" <NO_joeyong_SPAM@xxxxxxxxxx>
- Date: Thu, 6 Jul 2006 15:24:34 -0700
You already have a few good ones from other folks. Here are a few more:
- Can't verify application behavior in a failover. Nothing's free or
automatic; work is either done for you by the folks in Redmond or your own
apps dev team. If your apps are not failover aware, they'll toss an error.
If they are failover aware, they might auto retry, notify user, etc...
- Can only guess failover time unless your test bed is the production system
(if they say yes to this, maybe you should find a new company?). Most
cluster servers will failover within 8-10 seconds at the infrastructure
level. SQL Server 2000 then takes anywhere from 30 seconds to minutes before
it is online again depending on configuration, app behavior, hardware,
firmware, etc.... This is what I've seen on a number of different
machines/setups. You need to find your numbers. Also, SQL Server 2005 does
come back online faster (fast recovery can help quite a bit).
- Can't check for application behavior that may cause unexpected problems in
a cluster but not appear in a standalone server. For example, some wacky
report may peg the CPU preventing even the isalive check from executing thus
causing a failover but in a standalone, you'll only have poor performance
for a while then things are back to "normal".
- Patching/upgrade behavior. How are you gonna test firmware upgrades, OS
and SQL Server service packs, etc... for downtime?
- Running sqldiag would take a few more steps (ok minor nitpick)
Good luck with the managers. :-)
joe.
"M." <M@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F7D5F1AC-EB14-4E6A-9D91-8EE258365A40@xxxxxxxxxxxxxxxx
Rodney, Thanks for you input but I gotta tell you, that was not very
helpful.
Want I need are facts, not even trying to convince them is not an option.
Can
you share some facts such as:
1. A non-clustered environment would not allow accurate stress testing do
to
the inability to produce fail-over.
2. Clustered environment may run (maybe 5%???) slower due to the addition
resources required by the clustering services.
Etc.
"Rodney R. Fournier [MVP]" wrote:
I would love to help, but if they don't know all the components of a
truly
High Availability system, then all hope is already lost. HA has to start
at
the top and work it's way down. If the top does not understand what a
test
cluster would do, then I would not even try to convince them. It's sad
really.
Cheers,
Rodney R. Fournier
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
ClusterHelp.com is a Microsoft Certified Gold Partner
"M." <M.@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7339B6EF-0EE2-4490-BB6C-EBF0579D7788@xxxxxxxxxxxxxxxx
I am trying to convince "the powers that be" that we must cluster our
test
environment if we are definitely clustering our production environment.
The
question I need the community's help with is: WHY?
Can you give me some hard facts as to why it is not recommend to
cluster
one
environment and not the other?
I will have to compile a document to help prove and validate this
point.
Environment Facts: The database size will be over 300gb and the number
of
users will scale into the hundreds.
Thanks.
.
- References:
- Re: Why Cluster in a test Environment?
- From: Rodney R. Fournier [MVP]
- Re: Why Cluster in a test Environment?
- Prev by Date: new cluster server wizard freezes when it analyzing configuration step performed
- Next by Date: Re: Cluster and attached RAID performance
- Previous by thread: Re: Why Cluster in a test Environment?
- Next by thread: Re: Why Cluster in a test Environment?
- Index(es):
Relevant Pages
|
