Introduction
Smedge is simple enough to use that you can run a render farm simply by simply double clicking the icon and letting it handle all the rest. However, this simplicity is actually built upon automated control of several components, which can be run independently. On a small farm, the simple automatic mode of operation is fine for the even minimally technically proficient artists and managers to get their rendering happening quickly and easily. On a larger farm, however, the overhead of the simplistic approach can become a burden.
Thankfully, Smedge components can also be easily configured for larger, enterprise scale deployments. Using a more deliberate and designed approach to running Smedge will allow you to gain significant performance increases, especially on dedicated rendering nodes, and allow scaling to a larger amount of nodes without the overhead of the unnecessary components running on each one. A customized deployment is also how you can work around complex networking issues, from subnets to VLANs to VPNs to cloud integration.
What is a large farm?
The definition of “large” and “small” is arbitrary, and depends a lot on your computing infrastructure beyond just the number of machines you are connecting. In general, if you have multiple devices for switching and routing on a network, multiple sub-nets, domain integration, or dedicated IT/networking staff, you should probably consider your farm to be “large.” If you are counting machines, anything above around 20 machines is probably sufficient to start being concerned about things to start thinking “large.”
Dedicating a Master
The Smedge operational default uses a “redundant master” system. This allows any node running the SmedgeMaster component to be able to take on the role of the actual acting Master seamlessly, at any time. On a small network, for example using Smedge to turn a handful of workstations into a rendering farm, this seamless functionality is useful, as you can start Smedge on any machine in any order and not have to worry about missing data or licenses. On larger networks, machines tend to take on specific roles without changing, and servers can run the long-term processes (like the Master and Engine) for a very long duration with minimal user interaction.
Default Component Startup
The simplest form of dedicating a master is to change the current system component configuration. This configures the components that the GUI is going to start by default, and effectively can limit operation to the machine currently acting as the master without having to change anything about how you start Smedge. Specifically, you can still just run the SmedgeGui component on every node, without having to worry about starting only the master or only the engine, using services or daemons, or doing any other special configuration.
To set these options:
- (If needed) Choose System > Administrator Mode
- Choose System > Components > Set System Default Component Startup
- Set the option for Start the Master to Do not start
- Click OK
Once you click OK, the master will send out the updated configuration to all connected clients. All SmedgeGui clients currently connected will immediately conform themselves to the options you send, and will stop the SmedgeMaster process if they started it. Further, they will remember this setting so that the next time you start SmedgeGui on this client, it will not start the SmedgeMaster component. The only exception is if the SmedgeGui client happens to be the machine that started the SmedgeMaster instance that is acting as the active primary master, which will remain running. This effectively dedicates this active master as the only master.
Use components directly
A more dedicated infrastructure can be developed by using the Smedge components directly. There must be at least one instance of the SmedgeMaster component running on your network for the system to operate, and you will want an instance of the SmedgeEngine component running on every machine you want to use for rendering. The GUI can then be configured not to start any of the components automatically, and you get complete manual control of which components are running on which machines.
The SmedgeMaster and SmedgeEngine components can even be configured to run as a system “service” or “daemon”. This type of configuration allows the component to start with the machine, allows the OS to ensure that it restarts if there is a problem, and separates the Smedge network operation from the console and users on the machines. (One caveat to using services/daemons is that the renderer must be OK running in that context; a specific example of a problem renderer is After Effects, which does not run correctly when run in the context of a system service.) The details of how to configure services depend on the platform, but the Smedge distribution includes helper scripts in the Utilities folder that can assist you to install services on each support operating system. Also see the Smedge Administrator Manual for more information.
Extreme Measures
As each component executable in Smedge is independent, one tactic you can use to ensure that no machines accidentally take on the master role when they’re not supposed to is to remove or rename the SmedgeMaster program file itself. There is no need for the executable to even exist on a dedicated render node or workstation that is never meant to be the master. You can create a modified deployment of Smedge that removes this program file and thus ensure that any node running this deployment will never be able to become master as the process won’t be available for it to even start.
Dedicating a master may also require you to point some nodes to that machine manually. You can configure how the client finds the master by command line or with a configuration file. You can also change the components that the GUI starts with command line flags that override the system default component startup settings. See the Administrator Manual for more details about the command line.
Dedicated Engines
When SmedgeGui is idle for a while, by default it kicks itself into “Engine Mode.” In this mode, the GUI is disconnected from the master and is nothing but a parent process for the SmedgeEngine component, which stays connected and continues to do work. This reduces load on the machine and the network. You can force this behavior and reduce load on the machine even more by simply running the SmedgeEngine component directly instead of the GUI. You can use services, startup folders, or a scheduled task to start the engine component directly, and use the command line to configure how the engine finds the master, if needed.
Engine configuration service
It’s important to remember the distinction between the “SmedgeEngine” and the “Engine” components included in Smedge. SmedgeEngine is the process that manages the actual work done on the system, and Engine is a command line shell that configures engine settings. A typical configuration has the SmedgeEngine component set to run as a service on a machine, and uses the Engine shell to enable or disable it when a user logs on or off the console.
Because the Engine command line shell works by communicating with the master, it can take a bit of time for the enable/disable process to complete, which can delay log-on or log-off from a machine as the script waits for the response over the network. To alleviate this delay, you can configure the Engine command line shell to also run as a service, which offloads the delay to a background process during the operation of your log-on or log-off script. Essentially, your script will send the request to the Engine control service, which forwards it to the master and waits for the response, allowing the script process to run asynchronously.
Conclusion
This covers the most important configuration details that differ between a small deployment and a large one. You should explore the options in the Administrator Manual for more details about how these systems work, and for other options available to you that may become important in a larger network, especially the capabilities for integrating Smedge into larger pipelines with other tools. As always, feel free to contact support@uberware.net any time for additional support and assistance with configuring Smedge for your network.
