Wowza load balancing is a must for any multimedia content delivery application and should come as a standard feature with any quality CDN service. Beneficiaries should not be expected to explicitly ask for load balancing when contracting the development of a Wowza based delivery service. Load balancing sustains increasingly heavier traffic and allows dynamic resizing of the deployment network depending on demand and costs. So let’s look at the most common load balancing schemes and when to use one or the other.

1. Parallel

The most straight forward form of load balancing is the parallel scheme. This involves having multiple independent servers running the same application. An external load balancer then needs to direct clients to the less-used server. However, that is not enough, when the concept of a room is introduced. A room defines a group of clients with a common purpose, all of which need to be connected to the same server. For example, in a chat application, all the participants connect to the same server to consume others’ posts and post their own input to others.

Usage

• 1-on-1, many-to-many and one-to-many applications

Advantages

• Easy to implement even in systems that did not have scalability planned in their design
• Low latency
• Clients easily trackable
• Very easy to add or remove servers to/from the deployment scheme
• Does not need special Wowza configuration

Disadvantages

• Limited number of concurrent clients per room
• Difficulty in estimating the growth of the room’s clients’ number when assigning a server to the room. This could lead to random server overload
• No backup connection possible

2. Origin-Edge

The edge-origin scheme is natively supported by Wowza and is a highly tested solution that replicates the origin’s stream on any number of edge servers. The flow is controlled from the edge tier. Dynamic connections are possible. There is also an origin-based load balancer implemented for this scheme. It takes into account each edge node’s load and KPIs when redirecting clients to a particular server from the available set.

Usage

• one-to-many applications

Advantages

• Ability to serve much higher numbers of clients than the parallel scheme
• Load balancer can dynamically assign edge servers as load on each progresses, thus eliminating the risk of random overload
• Easy to configure due to Wowza native support for edge and origin applications
• Very easy to add or remove edge servers to/from the deployment scheme
• Static origin binding can be used with multiple origins both for load balancing and backup against origin failure
• Dynamic origin binding allows any edge to connect to any origin on demand
• Can be set up for systems that previously had no load balancing provided that they do not use any type of client-to-client RPCs through the Wowza application
• Can use a native Wowza implementation for the load balancer as well as an external load balancer
• Low inter-server bandwidth footprint

Disadvantages

• Client-to-client RPCs not possible between clients connected to different edges and origins
• First-time stream consumption from an edge may introduce delay on delivery as it connects to the origin and the buffer gets filled

3. Layered Origin-Edges

The edge-origin-edge scheme is a variation of the edge-origin scheme and introduces the notion of intermediate origin layer. This setup is preferred by most CDNs because it allows massive scalability that can potentially reach millions of concurrent clients. Another appealing capability is the ability to separately manage sub-networks. Using this architecture, you can have a large number of independent networks acting as resellers for centrally generated content.

Usage

• one-to-many  applications
• massive content distribution networks

Advantages

• Ability to serve greater numbers of clients that the other schemes
• Easy to configure due to Wowza native support for edge, origin and edge-origin applications
• Very easy to add an edge (or edge-origin) server to the deployment scheme

Disadvantages

• Client-to-client RPCs not possible between clients connected to different edges, origins, and edge-origins
• Removing an edge-origin server from the deployment scheme may disable a large sub-network
• Dynamic origin binding is no longer possible
• The native Wowza implementation for the load balancer needs to be set up separately on each edge-origin and cannot load balance the whole deployment infrastructure, thus the need for external load balancers that monitor sub-networks or the whole system when assigning servers to clients
• First-time consumption from a lower level may introduce a large delay on stream delivery as each node connects to its subsequent origin and buffers are filled
• Each additional level introduces latency due to buffering

4. Star Balancing

The most interesting type of load balancing is the star scheme. This allows very dynamic interactions between servers. Besides allowing geographical server assignment, it also enables any client to access any other client’s stream through the fastest connection possible. This setup is the way to go for large scalable many-to-many applications as it offers the best QoS and flexibility in such scenarios.

Usage

• 1-to-1, one-to-many, many-to-many  applications
• appropriate when client-server bandwidth is critical

Advantages

• Very dynamic and extendable
• Offers great opportunity for geographical pairing of clients with servers
• Easy to add and remove a node to/from the deployment scheme as needed
• All nodes work both as origin and edge

Disadvantages

• Client-to-client RPCs not possible between clients
• Requires low-latency server-to-server connections
• Supports lower maximum traffic than the other schemes
• Difficult to handle the complexity of the deployment scheme
• Difficult to keep track of client-servers pairs
• Web-service synchronization is demanding due to the large number of connections in a typical flow
• Static origin binding is no longer feasible
• Harder to configure than the other schemes
• The native Wowza implementation for the load balancer cannot be used
• First-time stream consumption may introduce delay on delivery as it connects to the origin and the buffer is being filled
• Larger inter-server bandwidth footprint

Note: I’ve only used this scheme for research purposes and never in production. In 2014 when I last played with this concept, there were reliability issues. Sometimes the stream came out black for end clients. As far as I know, Wowza did not officially support this setup and when asked, they always pointed to static origin binding. If you are seriously considering using dynamic origin binding in production, I recommend getting in touch with Wowza support.