Load balancing Evertz Mediator-X
About Evertz Mediator-X
Evertz Mediator-X unifies content acquisition, content processing, media management, production, playout, and delivery into a single, integrated environment. The unification of these services on a single platform delivers optimized media workflows and increased operational efficiency.
Built on over fifteen years of Mediator product development and deployment expertise, Mediator-X has a modern, scalable, infrastructure-agnostic architecture which can be deployed in public cloud, private cloud, or hybrid environments, enabling users to be flexible with their deployment strategies and to grow the platform wherever the business case dictates.
Loadbalancer.org
For high availability and reliability Evertz recommends Loadbalancer.org appliances to load balance the Mediator-X platform. Loadbalancer.org’s engineers have a wealth of experience, both with Evertz Mediator-X platform deployments and with the wider broadcast media industry. And the company’s expertise in achieving zero-downtime means that clients can rely on Loadbalancer.org’s knowledge and industry-leading support to always keep the show on air.
Key benefits of load balancing
Loadbalancer.org specializes in providing application delivery controllers (ADC). Load balancing Evertz Mediator-X ensures:
- optimized performance
- resilience (high availability)
- scalability
How to load balance Evertz Mediator-X
Sizing, Capacity, and Performance for a Virtual Load Balancer Deployment
The Loadbalancer.org appliances can be deployed as virtual appliances.
For small deployments handling up to 300 concurrent connections/users, your virtual host should be allocated a minimum of 4 vCPUs, 4 GB of RAM, and 20 GB of disk storage.
For large deployments handling over 300 concurrent connections/users, your virtual host should be allocated a minimum of 8 vCPUs, 8 GB of RAM, and 20 GB of disk storage.
For significantly larger deployments, your Evertz representative will give you custom sizing and resource guidelines based on the expected load on your load balancers and your predicted usage profile.
Persistence (AKA Server Affinity)
For the layer 4 DR mode scenario, each virtual service uses source IP address based persistence.
For the layer 7 load balancing scenario (the configuration that adds TLS based encryption), the persistence mode X-Forwarded-For and Source IP is used. This uses X-Forwarded-For HTTP headers as the primary persistence method, with source IP addresses used as a backup persistence method.
Virtual Service (VIP) Requirements
To provide load balancing and HA for Evertz Mediator-X, the following VIP is required:
- Mediator-X Global Access
The “Global” virtual service handles Mediator-X user interface traffic and API endpoint traffic. “Global” access to both services is provided using a single virtual service on the load balancer.
Additionally, a TLS/SSL termination service is required for the scenario that adds TLS based encryption.
Port Requirements
| Port | Protocols | Uses |
| 80 | TCP/HTTP | Mediator-X user interface access, Mediator-X API endpoint access |
| 443 | TCP/HTTPS | Mediator-X user interface access over TLS (optional) |
TLS/SSL Termination
It is possible to configure a TLS/SSL termination service in front of the plaintext, port 80, HTTP based Mediator-Global service. This enables inbound client connections to be secured using TLS. Connections from the load balancer to the Mediator-X servers remain as plaintext HTTP connections (not encrypted) on port 80. In this way, inbound client connections can be secured using encryption without needing to make any changes to the back end Mediator-X servers.
deployment guide
Evertz Mediator-X Deployment Guide
Read deployment guidemanual
Administration manual v8
Read manualcase studies
Ross Video
Read case study
mymovies - Delivering secure, reliable video content
Read case study
