Skip to main content

Scaling Services

Morio can scale horizontally by creating a larger cluster. But flanking services can also be scaled without changing the number of nodes.

Scaling non-flanking services​

Non-flanking services can only be scaled by adding more resources:

  • Horizontal scaling: Scale by creating a larger Morio cluster
  • Vertical scaling: Scale by adding cores/memory to nodes
Limits of dynamic scaling

Note that there are strict limits to dynamically scaling non-flanking services:

  • Horizontal scaling: Growing an existing cluster with additional broker nodes is (currently) not supported. You will need to redeploy a larger cluster.
  • Vertical scaling: Adding cores to a broker node is currently not supported as the core count is used for sharding inside the broker.

Adding memory is always ok.

Scaling flanking services​

How these flanking services can be scaled depends on the specific service.

Flanking services scaling scenarios​

  • Horizontal scaling:
    • Scale by adding flanking nodes
    • Scale by running multiple instances on different nodes
  • Vertical scaling:
    • Scale by running multiple instances on the same node
    • Scale by running more threads

Flanking services scaling support​

  • Cache Service:
    • Only one instance supported
    • We recommend to scale vertically by adding memory
  • Connector Service:
    • One instance can be deployed on multiple nodes
    • Multiple instances are not supported
    • We recommend to run a single instance on a single node and ensure it has enough cores/memory
  • EdA Service:
    • Multiple instances are supported
    • One the same node or differnet nodes
    • Horizontally scaling the same instance is not supported
  • SNMPProxy Service:
    • One instance can be deployed on multiple nodes
    • We recommend scaling this service vertically by adding cores/memory
  • SNMPTrap Service:
    • One instance can be deployed on multiple nodes
    • Running multiple copies is a good approach when combined with a round-robin DNS record
  • Tap Service:
    • Only one instance supported
    • Number of threads to run can be configured
    • We recommend to scale vertically by increasing the number of threads ot run
  • Watcher Service:
    • One instance can be deployed on multiple nodes
    • This does not really provide scaling as all nodes would run all checks
    • We recommend running a single intance on a single nodes and ensure it has enough cores/memory

Configuration syntax​

The overall syntax is always:

services:
  [service]:
    instances:
      [id]:
        nodes:
          - node1.example.morio.it
          - node2.example.morio.it

Where:

  • [service] is the name of the service
  • [id] is the id of the scaling instace. When a service supports multiple instances, you can choose the ID freely. When it only supports a single instance, the id is always single to make this limitation intuitive in the settings.

Examples​

Scaling the cache service​

Only one instance is allowed, so you configure it as:

services:
  cache:
    instances:
      single:
        nodes:
          - node1.example.morio.it

Scaling the eda service​

This service supports CNI scaling, so here’s an example to run multiple different instances on different nodes:

services:
  eda:
    instances:
      sales:
        description: EdA instance for the sales team
        nodes:
          - node1.example.morio.it
      support:
        description: EdA instance for the support team
        nodes:
          - node1.example.morio.it
      sandbox:
        description: EdA instance allowing people to learn Node-RED
        nodes:
          - node2.example.morio.it