SystemLink Enterprise requires an external MongoDB database. You must provision and manage your own MongoDB replica set or sets before deploying SystemLink Enterprise. This section outlines deployment options, required database credentials, and connection string configuration.

Important SystemLink Enterprise requires MongoDB to be configured as a replica set. Single-node standalone MongoDB instances are not supported.

Migrating from In-Cluster MongoDB

If you are upgrading from a SystemLink Enterprise version that used in-cluster MongoDB, you must migrate your data to an external MongoDB replica set. For migration instructions, refer to the release notes.

MongoDB Deployment Modes

MongoDB is a core dependency of SystemLink Enterprise. The deployment mode you choose affects the reliability, performance, and operational complexity of your SystemLink Enterprise installation.

Table 67. MongoDB Deployment Modes
Deployment Mode Reliability Performance Operational Complexity Notes
Single shared replica set for all services Lowest Lowest Lowest The shared replica set becomes a single point of failure. Resource-intensive queries from one service can affect all other services.
Hybrid: shared replica set for most services, dedicated replica sets for "hot" and performance-critical services Moderate Moderate Moderate Balances reliability and complexity. "Hot" services vary by customer workload.
Dedicated replica set for each service Highest Highest Highest MongoDB Atlas reduces the operational complexity of managing multiple replica sets.
Note Contact NI support to determine the appropriate deployment mode and identify which services are likely to be "hot" for your planned usage of SystemLink Enterprise.

Choosing a MongoDB Deployment

Most SystemLink services use MongoDB as the primary database. You must provision one or more external MongoDB replace set(s) before deploying SystemLink Enterprise.

The sizing recommendations in this document are only starting points for baseline deployments. Actual requirements can vary significantly based on your specific workloads and which SystemLink services you use most heavily. Some services such as the DataFrame Service may require substantially more resources than the baseline, and a single shared replica set may not be sufficient.

You must monitor MongoDB CPU, memory, and disk usage in production. Be prepared to scale resources or deploy dedicated replica sets for high-demand services. Contact NI support for workload-specific sizing guidance and review the DataFrame Service Sizing Examples (if applicable) before finalizing your MongoDB infrastructure.

Use the following table to choose the MongoDB deployment that best suits your use case.

Table 68. MongoDB Deployments
Deployment When to Use Details
MongoDB Atlas You want to simplify database provisioning, operation, backup, and restore operations. NI recommends using the following guidelines for your deployment.
  • Use a dedicated cluster replica set.
  • Ensure that each replica has 4 CPU cores and 32 GB of memory.
  • Ensure you have 512 GB of storage for the instance.
  • Deploy the instance in the same cloud provider region if your Kubernetes cluster is running in the cloud.
    Note You can use Atlas features to initialize a smaller instance and auto-scale as needed. Set limits to prevent costs from scaling beyond your budget.
Self-managed MongoDB replica set such as MongoDB Enterprise Advanced You want to control your database but require additional enterprise-level control.

NI recommends using the following guidelines for your deployment.

  • Use a replica set with at least 3 nodes.
  • Ensure that each replica has 4 CPU cores and 32 GB of memory.
  • Ensure you have 512 GB of storage for the instance.
MongoDB in a Helm chart such as the Bitnami MongoDB chart
  • You want your database in the same Kubernetes cluster as your SystemLink Enterprise installation.
  • Your organization is comfortable managing a MongoDB replica set.

You can run this replica set on existing Kubernetes worker nodes or dedicated worker nodes using taints and tolerations.

NI recommends using the following custom settings when deploying. You can adjust the requests and limits to fit with other pods on the Kubernetes worker node.

resources:
  requests:
    cpu: 4
    memory: 32Gi
  limits:
    memory: 32Gi
persistence:
  enabled: true
  accessModes:
    - ReadWriteOnce
  size: 512Gi
  annotations: {}
Note Backup and restore are critical considerations for all deployment types. You must plan and configure backup and restore procedures to meet your organization's data protection requirements, regardless of whether you use a managed service like Atlas or self-managed MongoDB replica sets.

Database Credentials

Each service requires a dedicated MongoDB database, user name, and password. Set passwords in systemlink-secrets.yaml.

Table 69. MongoDB Database Credentials
Service Database User Password
alarmservice nialarm nialarm alarmservice.secrets.mongodb.servicePassword
assetservice niapm niapm assetservice.secrets.mongodb.servicePassword
comments comments nicomments comments.secrets.mongodb.servicePassword
dataframeservice nidataframe nidataframe dataframeservice.secrets.mongodb.servicePassword
fileingestion files files fileingestion.secrets.mongodb.servicePassword
fileingestioncdc (optional) files files fileingestioncdc.secrets.mongodb.password
feedservice nifeeds nifeeds feedservice.secrets.mongodb.servicePassword
locationservice nilocation nilocation locationservice.secrets.mongodb.servicePassword
nbexecservice ninbexec ninbexec nbexecservice.secrets.mongodb.servicePassword
notification ninotification ninotification notification.secrets.mongodb.servicePassword
repository nirepo nirepo repository.secrets.mongodb.servicePassword
routinescheduletrigger niroutinescheduletrigger niroutinescheduletrigger routinescheduletrigger.secrets.mongodb.servicePassword
routineservice niroutines niroutines routineservice.secrets.mongodb.servicePassword
saltmaster minions minions saltmaster.secrets.mongodb.minionsPassword
saltmaster pillars pillars saltmaster.secrets.mongodb.pillarsPassword
specificationmanagement (optional) specifications nispecificationmanagement specificationmanagement.secrets.mongodb.servicePassword
systems nisystemsmanagement nisystems systems.secrets.mongodb.servicePassword
systemsstate nisystemsstate nisystemsstate systemsstate.secrets.mongodb.servicePassword
tags tags tags tags.secrets.mongodb.servicePassword
taghistorian taghistorian taghistorian taghistorian.secrets.mongodb.servicePassword
userdata niuserdata niuserdata userdata.secrets.mongodb.servicePassword
userservices keyservices keyservice userservices.secrets.mongodb.keyServicePassword
userservices users userservice userservices.secrets.mongodb.userServicePassword
webappservices webapps webapps webappservices.secrets.mongodb.servicePassword
workitem (optional) workorders niworkitem workitem.secrets.mongodb.servicePassword
Note Leave the password field blank to use a single credential set across all databases.

Connection String Configuration

Configure the MongoDB connection string or strings for your deployment based on the number of MongoDB replica sets. Use the connection string formats below.

Table 70. MongoDB Connection String Configurations
Deployment Type Configuration
Single shared MongoDB replica set

Set a global connection string in systemlink-secrets.yaml:

global.secrets.mongodb.connection_string: "mongodb+srv://<username>:<password>@my-atlas-cluster.mongodb.net/<database>"

This string connects every service to that replica set.

Multiple MongoDB replica sets

For each service in the Database Credentials table, set a service-specific connection string in systemlink-values.yaml. For example, to configure the Alarm service connection string:

alarmservice.mongodb.connection_string: "mongodb+srv://<username>:<password>@my-atlas-cluster.mongodb.net/<database>"
Note For services that appear in the table more than once, such as userservices, only set the connection string once.

Connection String Formats

Table 71. MongoDB Connection String Formats
MongoDB Type Format
MongoDB Atlas mongodb+srv://<username>:<password>@my-atlas-cluster.mongodb.net/<database>
MongoDB Community mongodb://<username>:<password>@host1,host2,host3/<database>?replicaSet=rs0
Note SystemLink replaces the placeholders in angle brackets such as <username>, <password>, and <database> dynamically when you deploy. You do not have to replace these placeholders manually. Type the string exactly as it appears unless noted otherwise

Additional Configuration

Contact NI support to determine the number of MongoDB replica sets and service-to-replica-set mappings for your deployment.