Skip to content

architecture

Axel Schwab edited this page Mar 11, 2024 · 2 revisions

High Level System Overview

The following image shows the general high level overview and the following key concepts:

  • To participate in a Winslow Cluster, it is recommended for the server to run the Winslow Docker Image. There is no additional installation overhead required. Winslow (and the start script) will automatically detect the available resources (like CPU, RAM and GPU).
  • A common network storage (like nfs) is required to be accessible by every Winslow instance of a Cluster
  • A user interacts with the system through the website. It can be hosted by any, all or no Winslow instance and it does not matter for the execution behaviour of the cluster.

architecture

Detailed

In the following diagram a more detailed view of the architecture of Winslow is described. Generally speaking, there are 4 levels:

  1. L1 describes the core business logic: when to execute what. It talks to L2 for storage IO and cluster synchronization, as well as to L3 to command Docker.
  2. L2 describes two storages. Firstly, synchronized storage used to exchange events with all other Winslow instances connected to the same Cluster through this storage. Secondly, a large file storage which is used to store resource and workspaces files of the projects.
  3. L3 describes the communication adapter to command Docker to execute a specific stage
  4. L4 describes an optional REST-API which talks directly to L2 to create, modify or delete projects, schedule executions, or to upload, download or delete files.

architecture_detailed

Event Publishing

Synchronization in Winslow happens through a series of events of which the order is unambiguous. To achieve this, each event has a sequence number. Events can cause effects that can alter the Cluster state (like locking a file). For failure resilience reasons, each such event has a timeout attached, after which the effect (for example the lock) is no longer valid. events

Publishing events on a file based storage (like nfs) ensures through atomic move operations, that one cannot publish an event before the current state is observed:

event_publishing

Failing to create an event file with the next known sequence number usually means, another instance already created an event file for that sequence number. It must be read before re-evaluating and re-trying to publish the event.

Class Structure

project-pipeline-definition

TODO: no longer up to date since ExecutionGroup changes have landed: there is now an ExecutionGroup in between Pipeline and Stage

Storage to Stage relationship

stage-storage

Clone this wiki locally