Deployment Planning

Understand EchoSystem

EchoSystem is a computing platform specifically designed to meet lecture capture and instructional production needs for educational institutions of any size worldwide. Designed to scale campus-wide over time, the system consists of specialized computing components which together form a comprehensive solution providing for all aspects of lecture and instructional capture.

Facilitating the management and monitoring of EchoSystem is the central EchoSystem Server (ESS) component. The ESS centrally manages production workflows, EchoSystem capture components, and presentation production, all of which are explained below. The ESS is a Java-based, modular server application which can provide, or be integrated with, other applications servicing the data infrastructure necessary to facilitate campus-wide deployment. The initial deployment of this data infrastructure is a key discussion in this document.

Automating instructional content production is core to the EchoSystem feature set. The EchoSystem employs both schedule-driven and faculty-driven automated workflows. Both are made simple to encourage lecture and instructional capture adoption. For details, see Workflow.

Organizational Planning Considerations

EchoSystem is designed to meet the lecture and instructional capture needs for institutions of any size. Any EchoSystem deployment requires proper planning, both to meet current demands and to provide for growth. This planning must include certain organizational considerations, such as those outlined below.

Appropriate Personnel

A successful EchoSystem deployment includes involvement of many groups within your institution. For a discussion of the EchoSystem components and their respective groups, see Deployment Guide. We recommend that you include the following groups in deployment planning:

• A/V Technicians
• Classroom Technology / Instructional Technology
• System Administrator (Server Management)
• Network Security (Firewall Management)
• Project Manager(s)
• CMS/VLE System Administrators (e.g. Blackboard, iTunes U)
• Programmers (System Integration)

Turnaround Time

EchoSystem processes (or packages) the media for students to view as a part of the automated workflow. This takes a certain amount of time after the recording is completed. The amount of time varies based on daily capture hours and media processing infrastructure. It is important to determine the acceptable time lapse between capture and student viewing. Consider the manageability of turnaround time: Students will come to expect presentation availability according to this policy and actual turnaround time.

Echo360 engineers can recommend a deployment design to meet the turnaround time expected at your institution.

Data Retention Policies

Capturing lectures and other instructional materials creates a large data set of valuable media assets. Some materials may only be suited for presentation to students during the current term. Others may have value for many years. Consider the value of the materials created as you develop data retention policies so you provide the best materials to students and minimize storage costs.

Your institution or central IT group may also enforce certain data retention policies enforced by the institution or central IT. Considering these factors will ensure you plan for storage appropriately.

Backup

Data backup is a critical consideration for every system deployment. Backup planning for the EchoSystem includes database, media, and application backup. Media backup policies directly affect storage planning.

Supported Technologies

For a discussion of support policies, see the Supported Technologies page.

When advising faculty on using Media Import, consult the list of supported tools and formats for Media Import.

System Planning Considerations

At a system level, meeting capture needs for institutions of any size is accomplished by two key aspects of the system architecture. The EchoSystem includes all necessary system services to begin capture production, offering a quick setup for pilot and initial deployments. Additionally, the EchoSystem architecture is modular, allowing it to utilize core services located on other systems. This architectural approach accommodates for a flexible, scalable computing infrastructure and seamless expansion as instructional material demand grows.

EchoSystem deployment typically follows a phased approach. A common adoption pattern for most institutions is to perform a small pilot, such as initial rollout to early adopters, followed by incremental growth as demand rises. This document is intended to provide guidance for initial deployment, with a view to future system growth. Echo360 Solutions and Deployment Engineers can assist with larger or more advanced deployments.

The sections below provide information about the various components of EchoSystem. Each of these components should be considered as you plan initial deployment.

EchoSystem Server (ESS)

The ESS is a Java-based server application. Consistent with server applications, ESS depends on other application services and supporting infrastructure to function.

Bundled Applications

An ESS installation includes bundled applications for each required service. Utilizing the bundled applications, with the exception of the database, is generally recommended for most initial deployment scenarios. The majority of these services can also be provided by third-party applications running on other systems. Please see below for a list of these services and the native ESS application supporting them. Supported Application Servers covers the deployment of these services on other systems.

• Java Application Server: ESS bundles Jetty as its native Java application service. This service cannot be provided on other systems.

• Database Server: You must use a third-party database server. For a list of supported third-party database servers see Supported Third-Party Components.

• Web Services: ESS uses Jetty for native web services. In this context, Jetty primarily provides for content delivery. Other web servers, such as Apache or IIS can be configured to provide this service. If you use an external Apache or IIS web server, see External Web Server Configuration for Live Chat for a configuration change that may be required.

• Flash Media Streaming Services: ESS supports the use of Wowza Media Server (Wowza) and Adobe Flash Media Streaming Server (Adobe FMS) for streaming of on-demand and live content.

• File Transfer Services: ESS bundles Maverick SSHD for native secure file transfer (SFTP) services. Other SFTP or FTP servers may also be used.

Establishing Temporary Storage

See Establish a Temporary Storage Location.

Supporting Application Servers

During initial deployment, it is important to consider expected growth of capture, processing and student review. This process may lead to the consideration of deploying some (or all) of the computing services required by ESS on other systems. Echo360 refers to these other systems as Supporting Application Servers. Considerations during initial deployment may include:

• Deploying a supported external database server during initial deployment removes the complexities of migrating data when growth warrants a more scalable database. In addition, an institutional policy may require the use of existing database infrastructure. In cases such as these, consider running ESS with one of the supported third-party database applications. If future growth is the driver for using a third-party database, consider installing it on the same computer as the ESS at initial deployment time. It can be moved to another server at a later time if necessary. The Server Installation Guide provides details for installing and configuring the ESS for use with third-party databases.

• Flash streaming infrastructure may already be provided by a central or department IT, or your institution may install Wowza Media Server or Adobe FMS for streaming of ESS content. In these cases, consider utilizing the preferred Flash streaming infrastructure for EchoSystem streaming services. The Administration Guide provides details for configuring the ESS to use alternate Flash streaming services.

• Presentation review volume may warrant separating the viewable media from the ESS. This will include utilizing a separate web server and Flash streaming server. This can be done during initial deployment or at a later time when demand increases.

• Captured media is transferred over the network to a file system accessible by the ESS for processing. Raw presentation files can tend to be large. Deployments with a consistent capture load through the day will benefit from moving file transfer operations to another server. Alternatively, the bundled file transfer server can be configured to run on a dedicated network interface. Such considerations are also covered below in Network Bandwidth.

Media Processing

EchoSystem licenses include an unlimited number of EchoSystem Media Processors. Media Processors package raw audio or audiovisual data from instructional capture into playback formats for students. Typically, one or more Media Processors will be deployed in an EchoSystem implementation to increase system scalability, performance and turnaround time for presentations. The application is supported on Windows and Linux computers. Media Processor installation on the same server as the ESS is not supported.

Media Processor deployment planning is primarily based on calculating the amount of capture hours per day and deciding on an acceptable (and reasonable) amount of time to make instructional content available to students after capture. Planning for initial deployment will generally be based on standard expectations. Capture appliances and Classroom Capture software devices upload captures for processing immediately after capture. It should be noted that network bandwidth will also affect turnaround time and is covered in a dedicated section below. The Personal Capture software differs from the other devices by allowing faculty to upload capture content at any time. The amount of processing required for Personal Capture content must be considered but might not be accurately predicted.

The physical (or virtual) hardware for each Media Processor is another key factor for planning. Transcoding, or video encoding in general, is CPU intensive. Faster processors (CPUs), more CPU cores, and larger L2 cache in the Media Processors greatly affects the speed at which instructional content is made available for viewing. Making informed hardware and deployment size choices in these early stages of implementation ensures better system performance and support for future growth.

As a general rule, processing will take up to 75% of the capture duration (or 3/4 real-time) for EchoPlayer processing when running on a dedicated CPU core. Vodcast encodings will take up to 50% of the capture duration (or 1/2 real-time). Media Processor deployment planning should consider a capture-to-core ratio to achieve desired results. The more concurrent captures that are running on a processor that has a dedicated core results in longer turnaround time. Less concurrent captures running on a dedicated core results in shorter turnaround time. This approach enables an initial deployment of a moderately specified Media Processor to handle expected capture volume while allowing for expansion, either by installing a more capable Media Processor computer or adding additional Media Processors, as demand increases.

Storage

Storage planning is vital to deployments of all sizes. Initial deployments should consider the advantages and disadvantages of using local storage or network attached storage. The EchoSystem produces large media files at various stages in the workflow. Media files can be grouped into three categories. Sizing information in this section is generalized for the purpose of storage planning. Actual sizes may vary in production environments.

• Raw Media Files: These are the high-quality source (master) files captured by EchoSystem capture devices. The size of this set varies based on capture device type. Capture appliances generate raw media files ranging from 300-600 MB per capture hour. Capture software generates raw media files ranging from 100-200 MB per hour. Personal Capture generates raw media files ranging from 500-1500 MB per hour.
• Podcast Media Files: These are the podcast and vodcast output format files, generally the smallest of the three categories. When produced together, these files range from 60-140 MB per capture hour.
• EchoPlayer Files: These are the files supporting the rich media playback experience in the EchoPlayer. EchoPlayer files range from 150-250 MB per capture hour.

The EchoSystem supports automated deletion of raw media files. Deleting raw media files will disable content editing. Therefore, media retention policies should be carefully planned and implemented at deployment time. The Administration Guide provides more information about automated raw file deletion and editing.

Network Bandwidth

File transfer and content service are both bandwidth consuming operations. File transfer occurs from capture devices to the network storage location and also from the storage location to Media Processor(s) and back. Media service occurs from the ESS (or supporting servers) to each student client computer. Networking best practices, such as network teaming, should always be adhered to.

Initial deployments may not produce the CPU or memory load to require supporting servers for the services mentioned here. However, when the ESS and related services are deployed on a single computer, network bandwidth may quickly pose a challenge for these services. In this case, the ESS can be configured to use different network interfaces for each service provided. Alternatively, supporting servers can also be implemented.

Refer also to the information provided in Bandwidth Requirements for Capture and Media Formats.

Capture

See Capture Options and Requirements and the sections on each capture device for deployment details.

Virtualization

A virtualized environment gives the flexibility to run multiple "virtual" machines rather than dedicated physical hardware for each server. Other benefits, based on virtualization licensing, can include the ability to move a running virtual machine from one physical server to another and leverage memory during file transfer within virtual machines. Virtual machines are more sensitive to disk IO, CPU and memory issues since numerous devices access the same physical machine. Consult individual virtualization documentation for best practices within your environment. Echo360 engineers can also assist in planning virtualized EchoSystem environments.

Other

Other considerations include:

• Firewall planning for the web, file transfer, and streaming services.

• Echo360 and Automatic Sync Technologies (AST) have teamed up to provide automated closed captioning and transcription services through EchoSystem. An account with AST and configuration of a publisher in ESS is required to enable this workflow. ESS web services must be open to the Internet for AST to make a connection back to ESS.

• Echo360 provides a hosted indexing service to enable the search feature in EchoPlayer. ESS web services must be opened to the Internet to enable this workflow.

Copyright Considerations

Customers retain ownership of Echoes and have the responsibility of adopting and implementing copyright policies for any such content.

The EchoSystem allows you to specify a copyright statement that is included in each Echo. See Branding.