[THIN] Re: Application Availability
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 7 May 2004 16:56:16 +0100
Comments inline...
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Shonk, Joe - Perot
> Sent: 07 May 2004 16:32
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Application Availability
>
> For several reasons:
> A dept/project buy a set of servers to deploy a single
> application
Numerous servers, single application - sounds good! ;-)
> Healthcare apps are very flaky. If an application
> takes down a server, only that application is down.
Do you / anybody actually run apps that can take down servers, these
days?
> It does
> not affect other critical systems
> Application limitations only allow 1 instance of
> whatever (database, group etc).
Then it's unlikely it would run in a PC environment, then (ie running on
numerous PCs).
The problem with an app just on one server, is that it's dependent on
that *one* server.
> There are many hospitals
> Application loads. Single applications can have
> 200-300 concurrent users a piece.
And it's extremely unlikely you'll get a single TS / Citrix server to
run that 200-300 concurrent users.
> Security/HIPAA requirements. Finance doesn't need
> access to clinical apps and doctors do not need access
> finance applications.
What's that got to do with an app running on just one server, though?
That's more to do with their environment providing access to the
application - not whether it's just published (or present for that
matter) on one particular server.
> Compatibility issues with multiple apps on a server
> (again see the flaky line above)
True - that can happen.
There's things that can be used, these days, to mitigate that.
But the flipside of it being that if an app is just published / present
on one server, and that server goes down, no app.
> Application maintenance. Different application sets
> have different maintenance schedules.
Agreed - I'm not against partitioning farms with applications (or
application sets) in mind - merely that just having one server for an
app certainly restricts your options, and resiliency.
> Taking one application
> offline and booting off the users should not affect access to
> other applications. (Remember this is a 24/7 shop)
That's no reason to just publish it (or have it present) on one server,
though - in fact it gives you a compelling argument to *not* just
publish (/ install) it on one server.
> Oh, and I forgot... The number #1 reason: Politics
Political and managerial people do not need to know that level of
detail, though (which servers, publish which apps) - that's a technical
decision.
> Never said it was perfect,
>
> Joe
>
>
>
> -----Original Message-----
> From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]
> Sent: Friday, May 07, 2004 1:26 AM
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Application Availability
>
> Comments inline...
>
> > -----Original Message-----
> > From: thin-bounce@xxxxxxxxxxxxx
> > [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Shonk, Joe - Perot
> > Sent: 06 May 2004 17:36
> > To: thin@xxxxxxxxxxxxx
> > Subject: [THIN] Re: Application Availability
> >
> > Why not use a custom load evaluator for the custom app? Then
> > script a logoff to force the users out of the application?
> > If the application set is isolated on it's own server then a
> > scheduled logoff ica-tcp is all that is needed.
>
> Why restrict yourself to only having an application on one
> server - this sort of thing (logging off user sessions, based
> on the published app they are running) then means you only
> take an application down, and can balance it, and have it
> benefit from the redundancy of being able to run over more
> than one server.
***********************************************
This e-mail and its attachments are confidential
and are intended for the above named recipient
only. If this has come to you in error, please
notify the sender immediately and delete this
e-mail from your system.
You must take no action based on this, nor must
you copy or disclose it or any part of its contents
to any person or organisation.
Statements and opinions contained in this email may
not necessarily represent those of Littlewoods.
Please note that e-mail communications may be monitored.
The registered office of Littlewoods Limited and its
subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB.
Registered number of Littlewoods Limited is 262152.
************************************************
********************************************************
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:
