I usually stop the nodes before the primary and start the primary before the nodes, but the order doesn't really matter. The object spawners will reach out to all others as they start up to establish which are available and perform leader elections.
When you stop the object spawner, any processes spawned by that object spawner will be terminated, so end users would be impacted.
@gwootton wrote: When you stop the object spawner, any processes spawned by that object spawner will be terminated, so end users would be impacted.
My 2 cents on this: I know this to be true for workspace severs (WSS's) launched directly by the spawner. But it is different for grid launched workspace servers. We routinely restart object spawners and never have WSS's terminating. I would expect many more calls from users if we would pull the rug from underneath them every now and then. The spawner asks LSF to launch the WSS on its behalf and there is no process parent-child relationship between them at the OS level.
Controller should always be the last to stop and first to start. Nodes can be any sequence. If you have dedicated queues for particular nodes that you might want to take that into account.
Restarting object spawner would kill all the SAS sessions spawned using it via Clients like EG/Studio or any other application configured to use Grid.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.