BookmarkSubscribeRSS Feed
☑ This topic is solved. Need further help from the community? Please sign in and ask a new question.
1 ACCEPTED SOLUTION

Accepted Solutions
gwootton
SAS Super FREQ
Usually when I perform deployments I only perform the compute tier install and configuration once for the grid controller, and share that sas install and sas config to the grid nodes. When using a shared SAS Config you would not use sas.servers to start processes on any host but the initially configured node (e.g. grid controller). Then you'd use the individual service commands to start services on the node.
Your configuration of having one compute tier on the grid controller and another for grid nodes is also valid though.
--
Greg Wootton | Principal Systems Technical Support Engineer

View solution in original post

6 REPLIES 6
mkiran
Obsidian | Level 7
I am performing new installation for M8 and completed below.

1. Metadata / Grid control - it has SASApp server and Object spawner to use as a compute for standalone tools. It is the LSF master too.
2. Grid Node 1 - Installed LSF and other SAS services like WIPDS, Stored process, Another application server for Grid ,Object spawner (second one - should I reuse the same one from Grid control server ? )

Both nodes are installed on a shared configuration directory.
And I see all services runnig properly on Grid node1 using sas.services script.

Do I need to perform any other configuration using SDW on Grid node 2 ?
How can I reuse the same sas.servers script on Grid 2 to start only the Object spawner with out starting other services like DIP, Locator, WIPDS, etc?.
gwootton
SAS Super FREQ
1. In this configuration you would not use the same object spawner between grid control and grid node 1.
2. No, you do not need to perform additional configuration on Grid node 2.
3. You would not use the sas.servers script to start the services on Grid node 2 for the reason you have identified, it would try to start services already running on node 1, you would just use the ObjectSpawner.sh script to start the Object Spawner on Node 2.
--
Greg Wootton | Principal Systems Technical Support Engineer
mkiran
Obsidian | Level 7

@gwootton : Yes I am not able to use the Grid Node1 Object spawner and grid node1 Application server loadbalancing with Grid algorithm(Only COST algorithm is available here).

 

Do you recommend configuring the Grid Node1 and Node2 on the same Grid Control server configuration (shared)?. In this architecture, I will need to select this shared config directory from SDW and merge these additional Application server node products. 

then I need to control sas.servers to control services on each respective node. Please suggest the optimal method for this configuration, we are flexible to perform the configs.

gwootton
SAS Super FREQ
Usually when I perform deployments I only perform the compute tier install and configuration once for the grid controller, and share that sas install and sas config to the grid nodes. When using a shared SAS Config you would not use sas.servers to start processes on any host but the initially configured node (e.g. grid controller). Then you'd use the individual service commands to start services on the node.
Your configuration of having one compute tier on the grid controller and another for grid nodes is also valid though.
--
Greg Wootton | Principal Systems Technical Support Engineer
mkiran
Obsidian | Level 7

We have one compute on grid controller (metadata also on the same) and I am getting Objectspawner and SASApp context with grid algorighm enabled.

And when tried to install Other grid node(using the provided plan file) , it is prompting to create a new Object sapwner and server context - may be I should reuse the existing ones from Grid Controller server instead of creating news ones on Grid1 and add node1 and 2 in the Objectspawner and SASApp load balancer.

 

FYI : Below is the planfile snippet.

 

mkiran_0-1714068298380.png

 

gwootton
SAS Super FREQ
Yes, that's what I do. I only install and configure the compute tier once, I do not use the plan file to configure grid nodes as well.
--
Greg Wootton | Principal Systems Technical Support Engineer

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 6 replies
  • 360 views
  • 1 like
  • 2 in conversation