Introduction to Kaltura’s On-Prem™ Solution
This document presents the basic and essential information about Kaltura’s OnPrem™ solution. This document is intended for organization business owners, video content managers and technical owners such as IT Managers.
Kaltura’s On-Prem™ Package is a solution that enables a customer to operate a fully-featured Video Management Platform on their premises behind a firewall.
The following components operate within Kaltura’s video platform:
Kaltura Web Services Module
The Kaltura Web Services module consists of an Apache server and Kaltura web services layer in the form of a set of Application Programming Interfaces (API) that serve as a single access point for client-server applicative communication. This module should be deployed on the front-end server/s, where traffic is distributed by a load balancing equipment.
Kaltura Batch Jobs Module
The Kaltura Brach Jobs module consists of scalable middleware entities that are deployed on back-end server/s. The Batch Jobs module acts as the central orchestration of atomic batch services such as media import, media information extraction, transcoding, server notification and other batch jobs. The Batch Jobs module should be deployed on a backend server.
Kaltura Transcoding Module
The Kaltura Transcoding module manages all media transcoding tasks, by utilizing open source and/or commercial transcoders. The Transcoding module is a CPU intensive module and may be deployed on a backend server at a local deployment or may be distributed using independent transcoding servers deployed in a cloud solution.
Shared storage contains dedicated disk space that is shared and accessible by all of Kaltura’s servers within a specific deployment. The shared storage holds all content and application files, including: media assets, Kaltura flash widgets/applications, skins, thumbnails, players/playlist configuration files (UI conf) and all other components. The shared storage may be deployed as part of a local deployment or using independent storage within a cloud solution.
The Operational Database is the applicative database, used for storing and managing content related data (metadata, identifiers, URLs and other relevant information.) as well as application and business logic supporting data. The Operational Database should be deployed as part of a local deployment, preferably on dedicated server/s utilizing a master/slave topology.
The Search Server includes full text search servers based on the Sphinx open source solution for fast indexing and search.
Site Admin Module
The Site Admin Module is responsible for operating Kaltura’s Admin Console, enabling site administrators to monitor and operate their own deployment of Kaltura’s online video platform. For full monitoring, it is important to deploy this module separately on a local server.
Video Analytics Module
The Video Analytics Module is responsible for processing and aggregating Kaltura’s video analytics data into a dedicated Data Warehouse (DWH), and the production of video usage and behavior reports. The module includes the data Exporting, Transforming and Loading processes (ETL), a DWH database, and the reporting utilities in use. This module can be deployed as part of a local deployment or can be distributed using independent analytics servers deployed in a cloud solution.
Video Recording Module (Optional)
The Video Recording Module is responsible for recording web camera streams; and is an optional component to be deployed only when there is a need to support video recording functionalities. Kaltura operates the Video Recording Module using the Red5 solution. Using a local Flash Media Server (FMS) of another provider is possible, but may require validation.
MediaSpace (Optional)Kaltura MediaSpace is a fully customizable media destination site for the organization. MediaSpace is an out-of-the-box video-centric site that can serve as a repository for media collections across an organization or a full-featured "internal YouTube. Kaltura MediaSpace may be integrated into the local authentication environment for role-based authentication, or used as a public destination site. Kaltura MediaSpace can be easily configured and branded, and requires minimal resources to get up and running while allowing extensive customization.
On-Prem deployment has two variations:
Deployment on one server that combines all modules into a single server and all share its resources (RAM, CPU, and HDD).
The single server deployment is usually not scalable (limited by physical resources of the single server) and typically used for small scale organizations with low traffic or for test/dev environment for the organization (not production environment.).
A single server can handle up to 1000 active user sessions and approximately 220 minutes of daily video uploads.
Deploy numerous connected servers. Each one operates as a different module in the cluster.
The multiple server deployment provides the ability to replicate a certain kind of module (for example the Transcoding Module or the Web Services Module) for improving management of multiple users and optimizing the server’s physical resources.
Multi-Server Diagram Example
On-Prem™ Multi-Server Diagram Example
Kaltura’s On-Prem Package enables you to customize Kaltura’s On-Prem solution to fit specific needs. Any configuration (features, SW components, special deployments or integrations) that do not match the standard are considered as ‘custom package’ and should be scoped by Kaltura.
You can customize the Custom Package solution in the following ways:
- Create a VM that has different SW components than the VM offered in the standard package.
- Install the solution on your HW or OS combinations, using the Kaltura installation file (tar) instead of the VM.
- Integrate with specific components (On-premise or not) that are not part of the standard package, such as CDNs, transcoders and other components.
These customizations should be clearly defined by the administrator and then scoped by Kaltura.
Choosing the Custom Package installation has the following implications.
- A unique environment is created that was not tested by Kaltura
- OS certification
- Riskier, harder and costlier installation
- Harder to upgrade to Kaltura’s solution
These are the general hardware recommendations for single and multi-server deployment. If not stated otherwise for a specific deployment in a specific project, these recommendations are effective.
Minimum HW requirements are:
- 8 GB RAM
- 2 quad core CPU
- Storage per need, according to expected usage estimations.
Kaltura’s recommendation and best practice is to have full redundancy of the modules for failover.
- 2 physical servers running a VMware 5.x ESX/ESXi Hypervisor. Each server will host several modules as VMs.
- 1 Platform Shared Storage - To be accessible by the Kaltura platform servers via NFS (RAID 5 or 10 is recommended). It is recommended to select hardware based on VMWare’s Hardware Compatibility List:
The following table indicates the minimum quantity and specifications, suitable for about 75K users.
With growth in service utilization, the initial setup can be scaled up as needed, to add the required server type (for example, additional transcoding servers, additional database servers for replications, additional front end server, and other server types.).
Minimal HW Requirements
Front-End API Servers and search servers
In high load cases, we may recommend a SQUID proxy in front of the Apaches. In this case Back-End Batch servers might also be needed.
2 search servers (Sphinx) for redundancy
2GHz, 64bit, 8GB RAM
1 quad core CPU
100GB of local HDD (100GB is recommended but not mandatory if local storage is an issue)
Back-End Batch Server
2 for redundancy
Back-End Transcoding Servers
Creating a video entry with multiple flavors can take up to 20 times the length of the source file.
2 for redundancy
Add more CPUs to be able to handle peak uploads
One master and one slave
One pair will suffice for ~75k users
DB Should be solid dedicated to the Kaltura platform
No minimal specifications on hardware
Admin Console and DHW Server
not exposed to the world directly - for security reasons
The app is not CPU intensive
No special storage required.
Optional - if MediaSpace is required Estimation - a typical server with 3GB RAM can support 100 concurrent requests ~1,000 concurrent users
Per SW requirements (FMS, Wowza, Red5)
Optional - if Webcam recording feature is required
Windows server 2008 Hyper-V licensing
1 quad core CPU
100GB of local HDD
Optional - if Video-PPT feature is required
Redundancy and Failover
In a multi-server environment, except for the Admin and DWH servers, Kaltura recommends servers to be in a pair pool. Pools can accept more than 2 servers when needed, for extra capacity.
Failover and load balancing should be enabled by Kaltura or the customer, depending on the server role. The Load Balancer (proxy/firewall/appliance) should be LVS based; running on a Linux server and fail over can be a scripted DNS change or may be changed manually in the configuration file.
Batch/ Transcoding Servers
The batch/transcoding servers are pool balanced via Batch Manager. The Batch Manager looks at all job requests and job status in the database. If the server is available for a job, it performs requests and flags the database accordingly. The Batch Manager also diagnoses job timeouts and failed jobs and reschedules jobs automatically.
Each batch/transcode server runs its own Batch Manager that determines its participation, or lack in the pool. Failover is dynamic, smooth and there is no impact on down time. Some performance degradation is likely (where requests are processed more slowly) due to the reduced number of servers, since one server has likely failed.
The API Servers should be load balanced, internally and externally, by proxy/firewall/appliance (active-active). This information should be delivered by the customer.
Sticky sessions are required for GUI sessions such as for the Kaltura Admin Console, Kaltura Management Console or Kaltura MediaSpace.
As in Batch, failover is dynamic, smooth and there is no impact on down time.
Sphinx Search Servers
Servers hold internal load balance logic in their code. The API servers direct actions to Sphinx server randomly.
Each Sphinx server indexes all data in real time so once a server fails, the failover mechanism is active.
These servers arranged in a master-slave pair.
All data reads and writes go to the master and replicates in real-time to the slave. Failure of the slave has no user impact, and carries minor risk due to lack of redundancy until corrected. On failure of the primary, the standard methodology for MySQL recovery is to update DNS to point the primary DB host name to the backup DB host IP address, until the primary can be recovered. This failover process is manual and failure carries significant impact until DNS is updated or the primary database is recovered. However, depending on the DNS server software and/or in conjunction with a remote monitoring server/service, automated DNS updates and/or database recovery routines can usually be developed and configured, reducing impact significantly. Another option can be set the slave DB to be used as primary in the DB configuration file.
DWH and Admin Servers
There is no need for redundancy and recovery may be manual. DWH processes analytics data collected from the DB on a daily interval. If the server cannot be recovered near real-time, it back fills automatically. Missing days of the Apache log data (up to the log retention period) automatically load once the DWH becomes operational.
This section describes the components included in the Virtual Machine of a Standard Package.
These SW prerequisites should be provided by the customer for a Custom Package. (For example in case the Kaltura install file is installed on your own HW or OS combinations).
with the following modules enabled - rewrite, headers, expires, filter, deflate, env, proxy
Prerequisite - The following RPM packages need to be installed from the distro's official repository:
php-gd php-pdo php-mysql php-pecl-apc php-soap php-common php php-pear php-xml php-devel php-mbstring php-xmlrpc php-cli php-pear memcached zlib.i686 bzip2-libs.i686 glibc.i686 ImageMagick ncurses-libs.i686 httpd java php-pecl-memcache mysql rsync cronie mailx postfix mod_ssl
Kaltura code is not needed on MySQL. Needs to comply with the minimum version of the MySQL DB supported.
Custom package Prerequisite - MySQL 5.1.33 or higher.
InnoDB and statement based replication.
Used by Pentaho for Analytics purposes
Also include the Pentaho data integration package.
Prerequisite - Pentaho 4.2.1 or higher
used for caching purposes to accelerate performance
Mailx is used by various shell scripts in order to send out mail alerts about various system events.
Custom package Prerequisite - An MTA such as: postfix, sendmail, exim or any other sendmail compatible variation is required to allow email delivery.
Required for installation
used by shell scripts provided with the Kaltura platform
Needed for scheduling various cronjobs, for both maintenance and daemon watchdog purposes
Use for creating thumbnails
Storage is always a customer responsibility, Kaltura will configure the mount for use.
Third party software bundled in the On-Prem package
Third party software bundled in the OnPrem package
Extract media data
Used for by the Kaltura transcoding decision layer
Third party software bundled in the On-Prem package
Used by Kaltura admin console
Third party software bundled in the On-Prem package
Optional component for webcam recording and live features. License can either be included or be purchased by customer separately.
Windows & Office
Should be provided by customer:
Optional, if Video-Presentation feature is required
The Standard Package includes integration with Akamai CDN for external delivery.
Any other CDN/CDS/p2p solution for internal or external delivery, Media server or Proxy integrations are considered as Custom package integration. For example: Limelight, Level3, Edgecast, Mirror Image, BlueCoat, Ignite, Octoshape, Adobe AMS, etc.
See the article Kaltura Supported CDN (Content Delivery Networks) and Streaming Servers for more info.
Video Delivery Format
On-Prem can deliver HTTP Progressive Download and HLS for mobile support.
Other delivery formats such as HDS, RTMP and RTMPE can be supported with the help of a Media Server that is required to segment and provision the format.
Live Streaming configuration in On-Prem is possible through the KMC for Akamai or Limelight customers (external delivery).
KMC can provision other sources than Akamai or Limelight (like Adobe FMS/AMS, also for internal delivery) using the API (This may require additional configuration. Contact your account manager for information about Professional Services. ). Additional information about configuring Live streaming is available in Kaltura Live Streaming Overview. and other related articles on the Knowledge Center.
Optional On-Prem Custom Features
On-Prem customers can choose to add or customize certain features as part of the Custom Package. The following table provides examples of several features that may be customized. Scoping is required prior to development and execution.
For additional details, please refer to the Professional Services Catalog.
Integrate with non-standard CDN Account
Integrating with non-standard CDN account (Amazon Cloudfront, Jetstream, Octoshape, Highwinds, Kontiki and more)
Custom Media Server
Integrating with customer’s Flash Media Servers (Adobe FMS or Wowza) - streaming server that can be integrated with Kaltura's On-Prem installation and enable webcam recording and other streaming use cases.
For officially supported versions only (for Adobe FMS Interactive server v3.5).
Local FMS should enable recording.
The KMC has English user interface. Kaltura offers the ability to change the default copy in English or translate to other languages.
Only for supported localization text and copy changes.
The default interface may already be available in a limited set of languages.
Requires a document that outlines a list of all KMC texts and screens for customer to provide requested text in English or other requested language
Changing underlining OS
Changing VM’s default OS (CentOS) to another (RHEL5, RHEL6, etc.)
Integration with a non-standard encoding/transcoding service or software (Rhozet, Harmonic etc.)
Include the customer’s logo and details instead of Kaltura’s details in every aspect of the management console and other interfaces
Requires graphics and spec from the customer.
Scanning the entries as part of upload process. Scanning by Symantec (licensed SW) or with Clam AV (Open source).
- Remote access is through one of the following:
- Cisco VPN
- PPTP (point to point tunnelling protocol)
- Remote access to different geographical locations for installing and testing (USA and Israel) should be available.
- Root Access to the entire environment during the installation phase is required.
- VPN login (if needed)
- Cross platform must be HTTP only, or HTTPs only (no mixed content). Kaltura recommends HTTPs - a prerequisite is to supply a signed certificate.
- The following tools are required for successful installation – Telnet, nmap, wget, tcpdump, traceroute, ping, Allow icmp during deployment, iptraf, iperf
- 100 megabit internal network bandwidth.
- Kaltura cannot run when the Security-Enhanced Linux (SELinux) feature is deployed and enabled. If the SELinux feature is deployed on the servers, it must be disabled or set it to permissive for being able to use Kaltura.
- In case you require HTML 5 support and your environment has security restrictions, you will need to provide enabled iPads and iPhones to the testing team (or make sure to enable your teams’ devices to work properly).
You will be responsible for e very tool or process that runs over the environment, and is not part of Kaltura product. Kaltura does not take responsibility, for investigating or fixing issues that are caused by the operation of this tool.
Kaltura’s extensions and features are available after On-Prem is setup, to create an improved and encompassing on-premise video management platform in your organization.
These extensions and features part of the On-Prem Standard or Custom Packages but as additional Professional Services offering, Please contact your account manager for details about Kaltura’s Professional Services.
- Single Sign On (SSO) - Integration with an external authentication server to enable external user management and access to already logged in users – as supported by KMS (not supported by KMC)
- Active Directory integration as LDAP, Shibboleth, SAML.
- Secured Login - Creation of an HTTPS certificate by the customer and integration effort
- The Kaltura Dynamic Player supports HTTPS, but requires to be set on the on the partner’s CDN configuration. The same is true for other widgets (for example KCW)
- Kaltura’s Video Building Block for Blackboard supports HTTPS from version 2 and on.
- KMC – Only the login page supports SSL.
- Admin Console – supports.
- LMS integration as Kaltura’s Video Building Block for Blackboard, Kaltura’s Video Package for Moodle, Kaltura’s Video Tool for Sakai.
- Kaltura Application Framework (KAF) for integration with third party products.