Object Spawner instance in 9.4

[doug_sas]

Customers may want to have one SAS application server context that uses grid-launched workspace servers and another that does not. Why? Some mid-tier applications create/destroy workspace servers frequently such that using grid-launched workspace servers makes the application appear slow.

[jakarman]

Doug, that are different functional systems

1/ using a midtier for web-access in a way that is trying to do a competition with the more normal LAMP stack. 

   It is very similar to the classic transactional systems on a mainframe

2/ using machines for real heavy analytics were the need for resources is high but the turn-around time is not that one in the order of seconds with transactions

  This is what in the classic mainframe is done by schedulers. The data-mining process grid processing is something that can be done with this.

For work of type 1/ you need machines with sufficient capacity. There is no easy way to spread or balance load in time (delayed processing)

For work of type 2/ you can balance that by differentating that in time. That is where the schedulers are having their place. Giving the load on the machine(s) in the moments where that is possible and do in an order so everything is ready in the planned expectation time.

As the machine capacity is limited you have to plan and manage those resources. That is workloadbalancing (WLM and scheduling).

LSF is more advanced as the simple single machine schedulers as it can balance the load across many machines.  As the speed of a core doesn't really increase anymore (https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf) this is an important feature.

You can load-balance with the Objectspawner for web applications (transactional) by defining them on several machines.

Using different app-server for each application, well that is in the name to segregate. It is for more astonishing seeing installation to be forced running as a sing app-server. The idea looks to be SOHO based (small office and home). The promotion for SAS is for big companies. The orion education is already having more than one. That is a misfit.

You can set up clustered metadata, clustered webservers, all for spreading load at some functional process.

The good news is:  that it is all possible.

The bad news is: it are all different technical approaches. Causing a lot of confusing. 

The ugly news is: By all that confusing there is a lot of trouble. SAS is far too difficult to be used for normal people  

For Linux there is a new promising WLM option at the OS level. cgroups - Wikipedia, the free encyclopedia. Tip review the SAS-VA manuals I found it there.

Going back to all those load balancing options as there must be some orchestration (no not that lsf part).  Having several drivers in a car each gas brake and steer is something of a comic. Would you do technical with cars it is more a crash to be happen that could be possible delayed by some magicans.

The original question is on the LSF grid implementation, within that I do not see room for others. (no object spawner present/needed)   (yes?)

[doug_sas]

When I say "app server contexts" I am meaning "SAS Application Server Contexts" defined in metadata that contain logical workspace servers, logical stored process servers, etc.

I am not talking about web application servers.

Maybe that caused some confusion.

[jakarman]

Doug ok, Let us go for that context of the word server in a SAS environment. A little bit hijacking the original question and at still very related to that.

I like that "SAS application server context" as it is bundling a lot. Although that word server. http://en.wikipedia.org/wiki/Server_(computing) it has that many meanings is some context. The hardware box, a logical part as virtual machine in that (see the list), a daemon process were sas is having a lot of those is one of them and all sas tiers being used.

Many IT architects do not understand that or do not want to understand that causing a troublesome relationship to sas implementations and usage.

Simple statements as an "application server"  is only to be allowed to be ..(your name here). At each server only one application being allowed to run. Every bare metal box must run many virtual machines as each applications is having as profile a low load. Or the most amazing of all: When running SAS bi/di server there is no need for SAS base/foundation.

The appserver context's are defined as part of the installation-configuration after the installation-installation. The first default appserver SASapp is the only one as it is the installation. An installation is a run once process.  I know it is wrong and humbug statements, these statements however are getting their own life.

Within that "SAS Application server context" there are a lot of files as config files with several of them usermod files that an admin can change for functionality.

These config files are just settings to what is going to happen when used. Other parts of those are in the sas metadata.

For the WS SP PWS is the objectspawner as demon that will start and monitor child processed.

for the Batch and grid servers it are possible an OS-scheduler like Cron or the LSF demon (grid) that will start and monitor child processes.

Seeing the docs of grid is the Grid server config files that are needed on each machine.

Nowhere is the sas objecstpawner in the non pdc node of the grid controlled machines seen (only lsf daemons) . Is that correct?   

When you are going for a grid you are going to combine a lot of machines (virtual machines) because your hardware is too limited for the expected load.

The situation in real life can be: having excellent hardware that could serve all load (and having wlm). By the VM dogma being split up in many smaller ones neither of them having sufficient capacity left. Then we go for building a grid of those smaller ones to get some better capacity. As it is all very complicated it is costly. Who is fooling who?   

When doing an implementation, architecture plan operational support these nasty details should be worked out in plans and descriptions.