HelixCloud Roadmap: Distributed Load


Published on

Provide a cost-effective and easy to use feature in order to distribute load across multiple servers, located in different geographic regions, according to their availability, resources and client's proximity

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

HelixCloud Roadmap: Distributed Load

  1. 1. Technical InsightDistributed Load
  2. 2. Target: Distributed Load"To provide a cost-effective and easy to usefeature in order to distribute load acrossmultiple servers, located in differentgeographic regions, according to theiravailability, resources and clients proximity"
  3. 3. Sample Architecture DiagramIn the left part of the diagram, the WebStream Clients are fed withlive and on-demand contents. The WebStream platform isdepicted in the central part of the diagram and provides the corefeatures, such as source streaming and platform management,including:● satellite polling component.● URL-redirection algorithm based on client location andsatellite subsystems availability.
  4. 4. Location ComponentsEach location features a subsystem which is made of the followingcomponents:● Helix Universal Server.● Helix Session Manager.● Middleware Adapter.Each subsystem is allowed to communicate two-ways with the coresystem:● from core network to satellite network:○ on-demand and live streaming.○ server remote-management.○ alerting and performance monitoring.● from satellite network to core network:○ authorization and access control.○ URL generation and redirection.○ logging and reporting data.
  5. 5. Helix Satellite ServersThe satellite Helix Servers are configured in a transmitter/receiver configuration with thecore Helix Servers. Communication between the core and satellite servers is based onunicast of one stream for each content (live or on-demand).The satellite Helix Servers operate to perform the required re-packetization (e.g. from mp4to Flash, or to iOS) and, for live streaming.The above process allows a great extent of bandwidth optimization:● on-demand clips are cached locally, therefore ideally only one transmission of anon-demand clip takes place between the core and satellite subsystems,independent from how many clients request that clip (e.g. 10 clients that requestclip xyz will generate traffic for just 1 clip between the core and satellite networks).Additionally future requests to the same clip should take place from the cachedirectly (when available) without further bandwidth usage.● live clips are broadcast from the satellite servers; between the core and satellitenetworks only one flow is activated, independent from the number of clients (e.g.10 clients that request live xyz will generate traffic for just 1 live between the coreand satellite networks).
  6. 6. Application Workflow
  7. 7. Application WorkflowThe previous diagram depicts the typical workflow when a user access the streamingcontent from a web front-end. The web front-end operates server-side to request thestreaming URLs from the middleware; the request includes also the requesting client IPaddress.The middleware performs, in sequence, the following checks:● the requested clip (on-demand or live) must exist.● access rules (for the clip) are satisfied.● run the redirection decision-maker algorithm in order to determine the list ofpotential URLs ordered by priority.● exclude from the redirection URLs those that might be unavailable (accordingto the data collected by the satellite polling component to the middlewareadapters installed at the satellite locations).● return the so determined URLs to the requesting client.
  8. 8. Application WorkflowThe web front-end loads the embedded media player with the provided URLs that arein turn requested by the media player.The media player contact the satellite servers identified by the URLs. The requests arehandled by the satellite Helix Servers that forward the request to the SessionManager which in turn send a Session Start request to the middleware.The middleware performs access checks and grant/deny access to the clipaccordingly.When access is granted, the media player starts playing the streaming URLs from thelocal system. When the player is stopped, the satellite Helix Server forwards theSession Stop event via the Session Manager to the middleware, which records the logfor reports generation.
  9. 9. Streamer Decision AlgorithmIn order to choose the best available server for a client, the middleware will beupgraded to support configuration of decision rules. Rules are base on networkaddresses and servers, so that each network will have a list of servers defined andconfigured along their priority, e.g.:● subnet a.b.c.d/16● priority 10: satellite-1.example.org● priority 20: satellite-2.example.org● priority 100: core.example.org● subnet e.f.g.h/16● priority 10: satellite-2.example.org● priority 20: satellite-1.example.org● priority 100: core.example.org● default (for undefined subnets): core.example.org
  10. 10. Thank You!Grazie!Danke schön!!‫ﺷﻜﺮا‬