Multi-Node Installation

This guide covers the NVIDIA Minerva platform deployment on a multi-node Docker Swarm. Services are managed by the svm script and grouped into four stacks: infra, tsservice, backend, and ui.

The installer can run in three deployment types:

Installation

The manager node is installed first; worker nodes join the Swarm afterward.

The following steps use the default-onemillion (3-node) template as the primary example. Adjust node counts and labels for other templates.

Step 1 — Manager Node: Run the Installer

Copy the installer package to the manager node and run:

chmod +x installer.minerva.<BUILD>\n./installer.minerva.<BUILD>

There are three different NVIDIA Minerva installer versions (installer version type will change the command above, if it is not the standard installer):

The installer prompts for configuration interactively. Enter ? at any prompt for a description of that parameter. Answers are saved on re-runs (upgrades), previously answered prompts are skipped.

Installer Prompts

Deployment Type

1. platform\n2. collector\n3. unified

Refer to Deployment Models for details on deployment type. For a hybrid installation, the Platform Stack must be fully installed before beginning the Collector Stack installation.

Platform Stack IP Address or FQDN

Enter Platform Stack IP address or FQDN

This is the address the Collector Stack will use to reach the Platform Stack. The TLS certificate is dynamically generated based on the provided FQDN/IP. The provided FQDN/IP must be reachable by the Collector Stack via port 443.

Kafka External IP Address or FQDN

Kafka external FQDN or IP Address for TLS listener

Same as Platform Stack IP Address or FQDN, unless the Kafka service has been placed on another node.

Container registry base path

Container registry base path

Docker registry path the installer will pull images from. Do not provide http:// prefix. If auth is required for the docker registry, run docker login on the node before continuing.

• NMC: Use nvcr.io

• Other: Installer has images bundled, leave this field empty

Additional platform TLS SANs

Additional platform TLS SANs comma-separated. Hit Enter if none

Defaults: localhost, 127.0.0.1, platform + Kafka address are always included. Use DNS:name or IP:address.

WJH gNMI dial-out username

WJH gNMI dial-out username. Hit Enter for the read-only default    [telemetry-ro]

WJH gNMI dial-out password

WJH gNMI dial-out password. Hit Enter to leave unconfigured

Time-series storage type

Where would you like to save the time series data?\n1. local \n2. s3\n3. azure\nChoose an option [default: local]

Backup destination for metrics kept in deep storage.

• Sub-prompts for s3:

  1. Time series S3 path

  2. Runtime AWS region for S3 access

  3. Use the existing AWS credentials file for runtime S3 access? [y/N]

     1. no → Runtime S3 AWS access key ID, Runtime S3 AWS secret access key, Runtime S3 AWS session token (optional).

• Sub-prompts for Azure:

  1. Time series Azure Storage account name

  2. Time series Azure Storage account key

  3. Time series Azure Blob container/prefix path
     

Support bundle upload to S3

Upload support bundles and support configs to S3? [y/N]

If yes, you will be prompted for a support upload S3 base path. If no, support bundles will still be uploaded locally.

Outbound proxy

Enter outbound HTTP or HTTPS proxy URL if any. Hit Enter if none:

Full proxy URL if required. Example: https://proxy.example.com:3128 . Leave blank if no proxy is needed.

VM resource template

Select VM resource template\n  1. default\n  2. default-highmem\n  3. default-onemillion\n  4. 832-onemillion\n  5. default-fivemillion\n  6. 3296-fivemillion

Select the template matching the provisioned hardware and expected ingestion rate. For single-node deployments use the default template unless otherwise directed by NVIDIA support engineers.

Backup schedule

Enter time to run backup jobs.\n  Format: <HH:MM>\n  Current time on host is <HH:MM> [01:00]:

Specify a low-activity time in the VM's configured timezone. If the VM runs UTC but the preferred backup time is 1 AM Pacific, enter the UTC equivalent.

Docker networking subnet

Enter an IP subnet for internal docker networking [192.168.0.0/16]:

Accept the default unless it conflicts with on-premises subnets used by monitored devices. Must be at least /24 .

Host time verification

Current time on host is <HH:MM> <timezone>. Press Enter if time is accurate\notherwise exit and configure correct time...

Verify the displayed time is correct. Any timezone is acceptable, but the clock must be accurate. Exit, fix NTP, and re-run if incorrect.

DNS verification

Make sure DNS is configured. Press Enter to continue...

Confirm DNS resolution works before continuing: nslookup google.com

RFC 3164 syslog timezone

Enter RFC 3164 syslog timezone [UTC]:

RFC 3164 (BSD syslog) messages do not carry a timezone. Specify the timezone of devices sending RFC 3164 syslogs using tz database format. Examples: UTC, America/Los_Angeles, Asia/Kolkata . Devices sending RFC 5424 are unaffected.

Ingestion rate limits

For each datasource:

<datasource> rate limit\nFormat: <count>/<duration> [300000/1h]:

Data exceeding the rate limit is dropped to protect VM resources.

Data retention

For each datasource (raw_v1 , system_v1 , packet_v1 , syslog_v1 , interface_v1 ):

Enter data retention days for <datasource> [<default>]:

Set retention appropriate for the storage allocated in the chosen template.

Setup name

Enter a unique name for this stack installation:

One-word name that uniquely identifies this deployment. No spaces. Example: acme-prod

Manager URL

Enter URL of the manager VM on the platform stack [https://<customer>.minerva.local]:

The URL used to access the NVIDIA Minerva UI. Used to construct permalinks in outgoing alert notifications. Example: https://minerva.nvidia.example.com

Backup destination

Enter backup destination\n  1. s3\n  2. local\n  3. all

Automated backups of configs and databases are stored at this destination. s3 uses a customer-supplied s3 bucket . all enables both s3 and local backups.

Auditing

auditd isn't installed. Please make sure to install it using instructions in README. Press Enter to continue...

If you get prompted to install and configure auditd, see Configure AuditD in the post-install section before performing steps under After the installer

Logrotate verification

Make sure logrotate is configured for hourly rotate. Press Enter to continue...

See Configure Logrotate in the post-install section before pressing Enter.

Kafka FQDN

Enter VM FQDN where kafka is deployed:

In a multi-node deployment with default placement, Kafka runs on the manager node — enter the manager's FQDN. If Kafka is placed on a worker via deploy-cfg.yml , enter that worker's FQDN. Kafka is accessed on ports 29093 and 9093.

After the Installer

Software is installed under ~/minerva/ :

cd ~/minerva

For a hybrid installation, after the Platform Stack is installed, locate the Collector Bootstrap Bundle (default path: ~/minerva/collector-bootstrap.tar.gz) and copy it to the collector node.

Step 2 — Manager Node: Obtain Worker Join Token

Retrieve the join token and swarm address for worker nodes:

docker swarm join-token worker

The output includes a --token value and an <addr:port> (typically <manager-ip>:2377 ). Record both for Step 3.

Step 3 — Worker Nodes: Run the Installer

On each worker node, run the installer in worker mode. Remember that you must run docker login on all worker nodes before running the installer.:

chmod +x installer.minerva.<BUILD>\n./installer.minerva.<BUILD> -p <registry-base> -s "worker <token> <addr:port>"

The worker installer downloads all Docker images and joins the node to the swarm. No interactive prompts are required.

Step 4 — Manager Node: Assign Node Labels

Node labels determine service placement and must be assigned before bringing up the stacks. For the default-onemillion (3-node) template:

# make note of node identifiers\ndocker node ls\n\n# host1 = manager node\ndocker node update --label-add worker=worker1 host1\n\n# host2 = historical storage and middle manager services\ndocker node update --label-add historical=yes host2\ndocker node update --label-add middlemanager=yes host2\n\n# host3 = timeseries DB router, broker, and coordinator\ndocker node update --label-add tsservice_rbc=yes host3

Replace host1 , host2 , host3 with the node identifiers shown by docker node ls .

Step 5 — Manager Node: Configure deploy-cfg.yml

deploy-cfg.yml under ~/minerva/, on the manager node, controls service placement and key operational parameters. NVIDIA support will provide a customized service placement configuration, as placement varies by hardware.

Do not edit deploy-cfg-default.yml — it is overwritten on every upgrade. All local configuration must go into deploy-cfg.yml.

Step 6 — Manager Node: Bring Up the Stacks

From ~/minerva/ :

./svm stack-up all

Stacks start in dependency order: infra → tsservice → backend → ui . Allow up to 10 minutes for tsservice to fully initialize.

Next: Collector Installation

Last updated: October 12, 2026