System architecture

System and architecture description

The Controller is a single access point to monitor components in your MediaKind solution, manage product users, and configure solutions from end-to-end. Configuration and control are separated for flexible resource allocation.

Software and applicative layers

The Controller design relies on a micro-services architecture to promote modularity and software component independence. The solution is split into a Front-End and a Back-End layer. Each layer is interfaced through a REST API.

⚠️

The Controller software relies on Linux. It runs CentOS version 7 (see release notes for details).

If menus or options in the web interface are grayed then contact your administrator about user rights.

UI Layer (Front-End)

The generic UI framework provides a same environment to display the web pages for all compatible products:

  • Web pages (services, servers, etc.) are shared across the product line.
  • Certain web pages are specific to each processing type (statistics, services, etc.).

API Layer (Back-End)

The Back-End features are triggered through a REST API that can be used either from a Command Line Interface, or from the Front-End Layer. The API layer allows:

  • A centralized redundant database.
  • The logic handling for cross-products and product specific features.

High availability

Access to the Controller is through a Virtual IP. This allows for a single connection access.

The Controller is based on an active/active implementation that ensures high availability.

The Controller database is synchronized in real-time between both nodes. In case of failure, the remaining node is instantly ready to process requests. If the primary server fails, then the Virtual IP is seamlessly re-assigned to the secondary server. This mechanism involves arbiter software, installed on a separate server. This arbiter server is in charge of electing the primary database if the network is partitioned (in the event of communication loss between synchronized databases).