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 5 Next »

The…

Up to 99.99% Availability

The following setup illustrates a typical bare-metal hardware environment. MediationZone is deployed in at least 1 site/region, with a minimum of 2 nodes.

Prerequisites for achieving high availability:

  • Redundant disk and database storage, that is configured to meet the availability target.

  • A High Availability Cluster Monitor 3PP. This application monitors process availability and health, and orchestrates an ordered fail-over when an issue is detected:

    1. Migration of the Virtual IP address.

    2. Mounting of storage.

    3. Startup of processes on the stand-by machine.

Up to 99.99% Availability via VM Failover

The following setup illustrates a typical Virtual Machine environment. MediationZone is deployed in at least 1 site/region, with a minimum of 2 compute nodes.

Prerequisites for achieving high availability:

  • Redundant disk and database storage, that is configured to meet the availability target.

  • A 3PP handling Virtual Machine (VM) monitoring and failover to alternate host. For instance VMWare vMotion, VMWare HA, AWS EC2 Auto-scaling, etc. The process monitoring/recovery is achieved by scheduling a script that starts all PICO processes not running on the local VM.

Up to 99.999% Availability Geo-redundant Deployment

A geo-redundant setup spans at least 2 sites/regions, minimum of 2 compute nodes per site/region. MediationZone can be deployed in an Active-Active or Active-Passive configuration.

Active–Active scenarios are typically used for real-time deployments, and consist of two independent sites/installations. Replication requirements:

  • Filesystem: not required.

  • System Database: not required.

  • Audit: not required.

  • Runtime state: optional, depending on use case. An example of a case where it is required is aggregation/correlation scenarios with database back-end, where the sites act as each others fail-over.

Active–Passive scenarios are typically used for batch applications, and consist of a single Platform instance running. The Passive site is a replica of the Active site, and needs to be started in case the Active site goes down. Replication requirements:

  • Filesystem: required when runtime data is stored to disk. For example File System aggregation/correlation and Duplicate UDR Detection.

  • System Database: required.

  • Audit: optional.

  • Runtime state: optional, depending on use case.

VM-based High Availability Deployment

The…

  • System Database external to MediationZone deployment, must be setup in HA mode

  • System availability via:

    • In case of VM failure the VM is migrated to an alternate host by the virtualization environment. Required for the ControlZone, use-case dependent for ExecutionZone

    • Filesystem mounted to all VMs if file-sharing between VMs is needed (which is common)

    • Each VM has local storage embedded in the image

  • Workflow availability via:

    • Platform process orchestrates workflow execution and failover across set of available ECs

    • Real-time collection workflows run as active-active across multiple ExecutionZone nodes. Traffic fail-over between nodes using:

      • Protocol-level failover for protocols that support it (Diameter, Radius. etc.)

      • Load balancer for all other protocols (TCP/IP, HTTP, REST, etc.)

      • Distributed VMs and ECs over multiple Availability Zones for extra redundancy

  • No labels