ASTRA Architecture

 

Standalone ASTRA Systems

ASTRA configurations start with a small standalone system that runs all applications on one ASTRA server (which can be mirrored).  In this configuration the server runs the MAM system, database, playlists, ingest, and the core ASTRA utilities.  Depending on the number of users and complexity of the playlists this configuration can control 4-8 playlists.

 


 

 

Standalone ASTRA system running all ASTRA applications, OR Typical Orbiter pod in a distributed ASTRA system

 

 

 

 

 

 

 

 

 

When the number of users, playlists or applications exceeds the capability of the standalone system, ASTRA expands into a distributed system using the same hardware as in the standalone ASTRA system.

Distributed ASTRA Systems - Orbiter

In a typical ASTRA MCR or ASTRA NEWS system, multiple Orbiter pods are connected to ASTRA BackOffice.   ASTRA BackOffice is the centralized location for the ASTRA MAM system and database.  It runs all the core system tools and shares resources with the Orbiter pods.

An Orbiter pod contains an ASTRA Server with serial control cards that is dedicated for playout, ingest or both.  They control up to 8 playlists, 48 serial ports, 15 GPI ports and TCP/IP connections to control devices.  Systems expand by adding additional Orbiter pods for additional playout or ingest channels.

Additionally the system can have a spare Orbiter pod.  This pod could be used when a pod is taken down for maintenance or in case of a pod failure.  It can also temporarily add extra channels for special events.

ASTRA BackOffice

ASTRA BackOffice contains the centralized database that is shared among all the Orbiter pods.  Below are typical applications that run on ASTRA BackOffice:

  • Media management including storage management, file transfers, and transcode control.
  • Database management including queries, import/export, and management utilities.
  • Synchronize NRCS and ASTRA MAM databases via MOS.
  • Ingest applications (requires serial control card).

Orbiter Pods

By off-loading
the database and media management tasks to run on the BackOffice server, more
complex playlists and devices can be controlled.  This distributed architecture provides the
user with greater flexibility in system design.

Typical Orbiter Design


Multi-Site Support

An Orbiter Pod can be on the same local network or can be located at a remote site and networked into the central site.  Control for a remote Orbiter can be from the central site, the remote site, or both.  This gives users options for managing multiple sites such as local control during one part of the day and remote control at other times.

Redundancy Options

The ASTRA servers used in the Orbiter pods or BackOffice can be mirrored.  When mirrored in the Orbiter pod, they require the ASTRA Serial Changeover Unit which switches serial and GPI device control from the main to backup server.  It is generally recommended for the BackOffice servers for its additional flexibility but is only absolutely required if control of serial devices is needed.