Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

The system architecture is designed to be completely distributed and scalable, capable of executing on various operating systems and hardware platforms.

Logically, the platform (the Platform) is layered into three different zones:

  • Access Zone is the layer where users access the system through a graphical interface or command line interface to perform operations and maintenance taks. 
  • Control Zone hosts configurations and provides storage and a range of services that are essential to the system.
  • Execution Zone is a scale-out layer that provides processing capacity in the system. This layer contains one or several Execution Contexts and Service Contexts, which are distributed over any number of servers.
    • Execution Contexts are responsible for executing and supervising workflows. 
    • Service Contexts host services that workflows running in Execution Contexts can share.

 The system processes in the various zones are referred to as pico instances and can be of different types:

  • Platform

  • Execution Context (EC)
  • Service Context (SC)
  • Command Line Tool (mzsh)
  • Desktop

The Platform, ECs, and SCs run in "containers", that are installed on one or more hosts. Each installation is assigned a container name to identify it uniquely within a system. One host, physical or virtual, may hold several containers, each one with a unique name and installed in separate home (MZHOME) directories. 

There are three types of containers:

  • The Platform Container runs the Platform and optionally EC and SCs. The Platform is always included in a Platform Container installation.
  • Execution Containers run ECs, and SCs. These pico instances are typically configured after the installation of the container.
  • The UI Container runs the Desktop interface.

You control the location of the ECs, and SCs via the System Topology Registry (STR), which is also used to set various system properties. For further information about STR, see System Topology Registry.

The figure below illustrates the system architecture.

  architecture


This chapter includes the following sections:

  • No labels