Omniverse Farm Installation and Deployments#

Introduction#

Farm consists of multiple services in a traditional Queue and Agent(s) architecture, which can be deployed in a variety of ways.

  • Farm Queue: Acts as the central scheduler, receiving and organizing tasks submitted by users. It maintains a list of tasks and assigns them to available agents for execution.

  • Farm Agent: Responsible for executing tasks assigned by the Farm Queue. Agents can operate on various infrastructures, including workstations, servers, or cloud platforms, providing flexibility and scalability.

The Farm Queue and Agent services are the same regardless of deployment method. The methods vary by their complexity of installation, scalability, reliability, and the environment in which they run.

Deployment & Installation options#

The Farm deployment options are summarized below. Once you’ve decided on the method that best suits your use case, in-depth installation and deployment guides are available from the menu on the left.

Once deployed, there are a variety of options available to further tune the individual services.

Omniverse Launcher (Farm 105.x & 106.x)#

Note

Deployment via the Omniverse Launcher will end with Farm 106. It has been succeeded by Farm Standalone.

The easiest method for deploying Omniverse Farm is by using the Farm Queue and Farm Agent applications available on the Omniverse Launcher. The Queue runs as a single process on a controller node and each worker node runs the Agent service. The Agent service can be configured to run one or more tasks based on the type of workload(s) and available resource. Scale and redundancy are a limiting factor in this deployment.

The Farm Queue and Farm Agent services are built on top of the Kit kernel, which can impose a constraint on the version of Kit used by applications when run on the Farm instance.

This is suited for small-scale deployment on Windows or Linux-based physical systems or virtual machines (VMs).

Standalone (Farm 2.x)#

The standalone deployment replaces the Launcher-based method for running Farm on Windows or Linux-based physical systems or VMs. It allows the Farm Queue and Agent services to be run in different configurations. They can easily be run together, queue only, or agent only to support a variety of deployment options driven by configuration files specified at startup.

This installation method does not require GPU resources, other than for Agents running GPU tasks.

Farm 2.x removes its dependency on Kit and relies on standard Python installation methods, requiring familiarity with entering commands in a terminal for both Linux and Windows installations.

Kubernetes#

For larger deployments, we recommend running Farm on Kubernetes. By default, Farm utilizes the Kubernetes scheduler to manage task distribution, with all Farm services deployed behind a load balancer to ensure failover and redundancy. This approach offers the highest scalability.

Cloud#

Omniverse Farm’s Kubernetes deployment supports Azure, AWS, GCP, and OCI. While Farm lacks native access control features for cloud environments, you can secure endpoints by utilizing tools like security groups or API Gateways. It is recommended to enforce stricter permissions for accessing management endpoints.

Deployment Alternatives#

Due to its microservices-based architecture, it is possible to mix deployment methods for the service components; for example, deploying the management services (Queue) in Kubernetes while using a standalone agent approach to distribute work across nodes.

Everything is API-driven and as long as the services can talk to each other, various deployment scenarios are possible.

Refer to Omniverse Farm Architecture for more information.

On this page