Ocalt Clusters

Overview

Your machines, one control plane. Group the machines you link with the OcaltQL Client into clusters, choose how each serves traffic and recovers from failure, deploy services and computational jobs on them, import a whole platform, and put your own CDN in front of it.

What it is

Ocalt Clusters groups the machines you have linked with the OcaltQL Client into clusters. Each cluster has an operating mode: failover with a primary and standbys, load-balancing across every machine, HPC for jobs split into tasks, or hybrid active-active with spares kept for recovery.

A machine is only ever in a cluster because you put it there, and a machine in several clusters is flagged so its shared load is visible.

What it does

• Deploys services onto a cluster from a bundle, a Git repository or a folder on another machine: the files are sent, installed and started on each machine, and a balancer in your namespace publishes them at an ocalt.site address. Instances that stop answering are taken out of rotation within seconds.
• Watches each cluster and starts the instances of a machine that went down on machines that are up. Runs computational jobs across workers, a task per command, or on a local fleet where the workers take tasks from a hub on their own network. Runs your own CDN: edge caches on the machines you choose, with cache rules, purge and statistics.

How it works

Machines are reached with DIRECTIVE, services run as processes on them with a tunnel each, the balancer runs in your namespace with WEBASSEMBLY SERVE and is published with SUBDOMAIN, and recovery is a WATCH. Every operation is a named command on the Ocalt app gateway, counted on your query meter.

Local fleet

A local fleet is a way of running, not a fifth kind of cluster: any cluster can use it. Clusters reads each machine's network, its address on the local network and the public address it reaches Ocalt from, and machines that share a network form an island. Inside an island the machines talk to each other directly, in milliseconds, instead of going through Ocalt for every step.

• Read the network: on a cluster, open Network and click Read the network. Each machine reports its local address, its public address and its processors. Machines on the same local subnet behind the same provider are drawn as one island at first; a run then settles it. A worker that reaches the hub over the local network confirms its island, shown as seen working directly, and one that is offered the local network and cannot reach it there is drawn apart. A carrier that moves a phone to another public address no longer splits a room in two.
• Run a job on the fleet: an HPC job can run on the fleet instead of a task per command. One machine of the cluster becomes the fleet's hub; every worker takes its tasks from the hub in batches and returns the results as it goes. A worker on the hub's subnet tries the local network first. Anywhere else, or when that does not answer, it reaches the hub over a DIRECTIVE peer link, direct when the networks allow it and relayed when they do not, and through the hub's own tunnel as the last way in.
• Balance a service on the local network: a service with instances on machines of one island can have a local balancer. One machine of the island runs it and sends each request to a healthy instance over the local network, so phones, laptops and screens in the same place use the service at its local address without a trip through Ocalt. An instance it cannot reach locally is reached through its own tunnel instead. Visitors on the internet keep using the service's ocalt.site address. Open the service, find Local network and click Balance on the local network.
• Mixed fleets: a cluster can mix islands, such as three machines on an office network and a server elsewhere. Each worker uses the fastest way it has to the hub, and the job page shows how each one is connected.
• When a machine drops out: the tasks it had taken go back to the queue when their lease runs out, and another worker runs them. A task that fails is tried again up to the job's retry count.
• The hub chosen is the online member with the most processors that is not a phone. You can choose another hub when you start the run.

Every machine in a fleet runs the OcaltQL Client. The hub and the workers are short Python programs that Clusters sends to the machines and starts with DIRECTIVE WEBASSEMBLY SERVE; the hub listens on one port, and only workers holding the run's token are answered. When the run ends, the hub and the workers stop, and the results are in the job like any other.

Who it is for

Anyone with more than one machine who wants them to share the work: a small team with a few servers, a lab with workstations that sit idle at night, or anyone moving a platform off rented hosting onto machines they already own.