nplus-component-nstl#

nscale Server Storage Layer, virtualizing the storage to be used by the nscale Server

Server Ids#

if you use nstlHA, both server must have unique server IDs. Since the probaly use the same license file, you can set it via

nstla:
    serverId: 4711
nstlb:
    serverId: 4712

to make this work, you must have a license without nstl ServerID in it.

High Availability#

nscale Server Storage Layer does not support multiple replicas because of configuration restraints. To get HA, nplus defines nstl[a-d].

If you want multiple server, just switch the single server nstl off and turn on nstla and nstlb [..] and configure them individually. You will find individual config directories on the conf shared volume for each nstl instance.

Cluster Service#

in HA mode, the Instance Chart deploys a cluster service that balances across nstl A and B. You can use it if you want, or you use the services for nstla and nstlb and load balance via nappl. Both is ok, it just uses different load balancers.

Remote Servers#

If you want to connect to nscale Storage Layer servers outside the cluster, you can add the IP Range of those server to open the firewall (if used):

nstla:
  security:
    cni:
      nstlIpRange: 89.207.132.170/24

Accounting#

You can enable accouting by setting accounting: true. This will create the accounting csv files in ptemp under <instance>/<component>/accounting.

Additionally, a log forwarder can be implemented to output the accounting log to stdout, so that your log aggregator is able to collect that information and add it to whatever tool you use for log monitoring / analysis.

You can optionally set the db path, where the logForwarder stores the information which log entry has been collected. If you do not set this, the default value is logs.db in the path of the log Pattern (of the pathvalue).

Example: (in Instance Chart)

nstl:
  accounting: true
  logForwarder:
    - name: Accounting
      path: "/opt/ceyoniq/nscale-server/storage-layer/accounting/*.csv"
      db: "/opt/ceyoniq/nscale-server/storage-layer/logsdb/logs.db"

The DA_HID.DAT#

the nscale Server Storage Layer offers a safety net, storing the latest ever assigned highest Document ID into a file called DA_HID.DAT. This file normally resides next to the Document Administration. However, in a production environment, you want to place this file on a separate disk to build a safety net for the case that you restore the DA to a former version so the counter starts assigning a document ID twice. So in nappl, you end up having documents with the same storage layer doc id.

This must not happen, so a good practise is to store the DA_HID.DAT on a second disk and have the nstl check it during startup. This is not the default, as it would not make a lot of sense until you really have a second disk.

To switch this on, you can place the hid file on the secondary disk (like in the example below). The path is mounted by default. Just set it and turn it on like this:

# -- enables checking the highest DocID when starting the server.
# this only makes sense, if you also set a separate volume for the highest ID
# This is a backup / restore feature to avoid data mangling
checkHighestDocId: "1"
# -- sets the path of the highest ID file.
dvCheckPath: "/opt/ceyoniq/nscale-server/storage-layer/hid"

Updating from Releases < 9.3 to 9.3#

With version 9.3, nplus introduces a new disk volume, to separate the arc Buffer and the retrieval Buffer from the data volume that holds the DA. This is necessary, as under heavy load it may result in performance loss because some cloud providers have iop limitations on volumes.

To make sure we stay compatible though, there is a new init container that copies the buffers from the old location on data over to the new location on disk.

Please make sure, you set the size, class and optionally the volumeName (in case of static volumes) according to your requirements.

nplus-component-nstl Chart Configuration#

You can customize / configure nplus-component-nstl by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

Template Functions#

You can use template functions in the values files. If you do so, make sure you quote correctly (single quotes, if you have double quotes in the template, or escaped quotes).

Global Values#

All values can be set per component, per instance or globally per environment.

Example: global.ingress.domain sets the domain on instance level. You can still set a different domain on a component, such as administrator. In that case, simply set ingress.domain for the administrator chart and that setting will have priority:

• Prio 1 - Component Level: ingress.domain
• Prio 2 - Instance Level: global.ingress.domain
• Prio 3 - Environment Level: global.environment.ingress.domain

Using Values in Templates#

As it would be a lot of typing to write .Values.ingress.domain | default .Values.global.ingress.domain | default .Values.global.environment.ingress.domainin your template code, this is automatically done by nplus. You can simply type .this.ingress.domain and you will get a condensed and defaulted version of your Values.

So an example in your values.yaml would be:

administrator:
  waitFor:
    - '-service {{ .component.prefix }}nappljobs.{{ .Release.Namespace }}.svc.cluster.local:\{{ .this.nappl.port }} -timeout 600'

This example shows .this.nappl.port which might come from a component, instance or global setting. You do not need to care. The .Release.Namespace is set by helm. You have access to all Release and Chart Metadata, just like in your chart code.

The .component.prefix is calculated by nplus and gives you some handy shortcuts to internal variables:

• .component.chartName The name of the chart as in .Chart.Name, but with override by .Values.nameOverride

• .component.shortChartName A shorter Version of the name - nappl instead of nplus-component-nappl

• .component.prefix The instance Prefix used to name the resources including -. This prefix is dropped, if the .Release.Name equals .Release.Namespace for those of you that only run one nplus Instance per namespace

• .component.name The name of the component, including .Values.nameOverride and some logic

• .component.fullName The fullName inlcuding .Values.fullnameOverride and some logic

• .component.chart Mainly the Chart.Name and Chart.Version

• .component.storagePath The path where the component config is stored in the conf PVC

• .component.handler The handler (either helm, argoCD or manual)

• .instance.name The name of the instance, but with override by .Values.instanceOverride

• .instance.group The group, this instance belongs to. Override by .Values.groupOverride

• .instance.version The nscale version (mostly taken from Application Layer), this instance is deploying.

• .environment.name The name of the environment, but with override by .Values.environmentNameOverride

Keys#

You can set any of the following values for this component: