[THIN] Re: Application Availability

  • From: "Shonk, Joe - Perot" <JShonk@xxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Fri, 7 May 2004 11:09:12 -0700

Comments inline...

>> For several reasons:
>>      A dept/project buy a set of servers to deploy a single 
>> application

>Numerous servers, single application - sounds good! ;-)

It's dependent on who provides the money.


>>      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 still happens...  Many of these systems are still 16 bit.

>> 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.

It works fine on a PC... The end user/PC only has to worry about the
version/configuration of the application for their particular area.  For one
application that is about to be deployed there will be 40 different
instances of it.  A PC can handle 1 instance, but a single MF server can't
handle 40.

Sometimes it does not run in a PC environment, hence why they run it off of
citrix.

>> 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.

No, they are not on a single server... That's the point, there are 7-10
servers allocated for one application set.  There is no point in bogging
them down further with additional applications.


>>      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.

That is why an application is installed on several servers and
load-balanced.  I stated that there is nothing wrong with a server hosting a
single application, but I never said anything about only a single server.

Granted some applications set are under utilized, that's were VMWare comes
into play.


>>      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.

How so?  Applications sets are across multiple servers.  By using ICA
Pass-through I can provide secure custom desktops easily to anyone without
having to creating 10s of different desktops.

>> 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.

Again, the applications sets are redundant across multiple servers.  Again
single application, not single 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.

Oh, but they do... or try anyways...  So who's providing the money to
upgrading an aging application.

> 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

********************************************************
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: